快速分批查找问题

whywen_MoJian 2010-04-27 11:08:37
怎么快速的分批查找数据
比如: 查id >1 and id < 3958670,里面共有905934 ,每500条查一次的
如果用Limit,前面的数据查找速度还是比较快的,但是到后面,如limit 705934 , 500
会特别的慢。。
...全文
76 12 打赏 收藏 转发到动态 举报
写回复
用AI写文章
12 条回复
切换为时间正序
请发表友善的回复…
发表回复
程序猿Eric” 2010-04-28
  • 打赏
  • 举报
回复
每天回帖即可获得10分可用分!
WWWWA 2010-04-28
  • 打赏
  • 举报
回复
就是用SP嘛,SQL语句基本没有优化方法了
whywen_MoJian 2010-04-28
  • 打赏
  • 举报
回复
[Quote=引用 8 楼 wwwwa 的回复:]
呵呵,可以考虑一下分区表之类 的方法。
[/Quote]

那个是什么表,表的结构是什么我都不知道,我只知道表的必须有一个主键那就是id
whywen_MoJian 2010-04-28
  • 打赏
  • 举报
回复
有个想法,但没想到有啥好的处理方法。
比如: 查id >1 and id < 3958670,里面共有905934 ,每500条查一次的
如果可以精确的知道第500个的位置,不就可以解决了吗?
假设从1开始,第500个的位置是id=1000,
再从1000开始,第500个的位置是id=1700,
........
一直这样算下去。。
WWWWA 2010-04-28
  • 打赏
  • 举报
回复
呵呵,可以考虑一下分区表之类 的方法。
whywen_MoJian 2010-04-28
  • 打赏
  • 举报
回复
[Quote=引用 4 楼 wwwwa 的回复:]
参考一下
http://topic.csdn.net/u/20100413/14/ba062a92-a32d-47f2-b37c-0bd46dc2fab9.html?17186
这个帖子的方法
[/Quote]

这个帖子看了,不错,速度是快了好多,昨天测试了,但还是不太符合要求
whywen_MoJian 2010-04-28
  • 打赏
  • 举报
回复
[Quote=引用 3 楼 wwwwa 的回复:]
用SQL语句似乎没有什么优化方法了,用SP试试
[/Quote]

不好意思,请问sp是什么?
ACMAIN_CHM 2010-04-27
  • 打赏
  • 举报
回复
[Quote]如果用Limit,前面的数据查找速度还是比较快的,但是到后面,如limit 705934 , 500
会特别的慢。。[/Quote]

没办法,因为MYSQL还是会先查出前面的705934条后再显示后面的500条。

WWWWA 2010-04-27
  • 打赏
  • 举报
回复
参考一下
http://topic.csdn.net/u/20100413/14/ba062a92-a32d-47f2-b37c-0bd46dc2fab9.html?17186
这个帖子的方法
WWWWA 2010-04-27
  • 打赏
  • 举报
回复
用SQL语句似乎没有什么优化方法了,用SP试试
whywen_MoJian 2010-04-27
  • 打赏
  • 举报
回复
id本来就是主键
WWWWA 2010-04-27
  • 打赏
  • 举报
回复
ID上建立 索引没有?
我们在下面的讨论中谈论Slack,但是这些问题同样适用于具有Slack会话模型的其他应用程序,包括Hipchat,IRC,Mattermost,Discord,Spark等。 任何经常醒来的人都可以告诉你,这并不有趣。 松弛未读 Slack渠道缺乏组织和上下文,这意味着大量使用Slack的人每天都必须手动浏览数百条消息以查找与其相关的内容。 松弛的渠道对于经理和参与多个项目的其他人来说甚至更糟。即便是对Slack的适度使用,每天导致的频道消息也比大多数经理有时间处理的消息还要多。 实际上,在使用Slack的组织中,许多高级人员(明智地)根本不阅读他们的频道消息,或者只阅读了一些较小的频道。这意味着您现在拥有一个公司沟通平台……除决策者外,其他所有人都可以。 频道每天收到数十条消息后,实质性对话变得越来越困难,甚至变得不可能。如果您在上午10点发送了一个深思熟虑的问题,那么午餐后登记入住的任何人都来不及回复,因为其他人已经在该频道中发起了另一个对话。这意味着即使是繁忙的频道也无法用于严肃的讨论,它们演变成快速提问和随机垃圾邮件的混合体。 这意味着,当每个人都在他们的键盘上时,不同时区的工作人员只能在狭窄的窗口内有效地进行协作。结果,Slack并不是用于远程工作的有效通信平台。 明确说明:制造Slack的公司拥有1000多名员工,但没有发布任何远程职位(您可以在任何地方工作的职位)的广告。 相比之下,Zulip团队有30多个核心团队成员分布在十几个时区,并且仅使用Zulip和GitHub问题进行通信(没有电子邮件列表,视频会议等)。 当每个人都在线时,Slack非常适合私人消息(“ DM”),集成和快速提问。关于Slack的大多数发光评论实际上就是Slack的这些方面。我们发现,即使是喜欢Slack的人也通常会在DM中发送其绝大部分消息,并避免使用公共Slack频道。 在采用Slack的组织中,采用Slack之前发生的事情几乎是相同的:电子邮件,会议和小组聊天。 电子邮件非常适合异步工作;这就是每个人都使用它的重要原因。正确使用电子邮件的简单主题行模型可以解决上述所有问题。但是,它太笨拙,无法进行对话。即使是10条消息的线程也很笨拙。而且它缺少现代聊天应用程序的许多对话功能,例如即时传递消息,键入通知,表情符号反应,注意事项等等。 会议是当前最先进的对话方式,例如经理,经理或其他高级人员等忙碌的人可以参加会议。但是,会议通常效率极低。如果在讨论的五分钟中只需要参与者的输入,则参与者可能需要出席一个小时的会议。如果某人无法参加会议,则他们的输入将丢失。必须有人记录下来,以便对发生的事情或任何后续行动进行记录。会议增加了延迟和安排决策的开销。 最后,小组聊天只能在短期内发挥作用,但是并不能在团队内部建立知识,只能使经理对项目有全面的了解。大型列表可以访问讨论,从而使更多的利益相关者可以参与其中。 这些问题都是以下事实的症状:Slack和类似工具使用的通道模型是构造异步通信的一种非常糟糕的方法。 但是,异步通信是当今工作方式的基础: 经理,PM和全天开会的其他人需要在会议之间的几分钟内或一天结束时分批答复。 与团队其他成员所在时区不同或工作时间表不同的任何人,都有一天的不同时间在异步工作。 如果每个贡献者需要每5分钟检查一次其通信工具以使用它,则无法进行重点工作。异步通信对于能够集中精力一个小时或更长时间至关重要,事实证明,异步通信对开发人员的工作效率和幸福感产生了巨大影响。 您无法在Slack通道中进行异步工作这一事实为Slack对组织的有用性设定了上限。 Zulip的独特线程使我每天与我们分布在7个以上时区的分布式工程师和PM团队合作节省了一个多小时。我们尝试了Slack,Mattermost和其他声称支持线程的团队聊天产品,但是没有任何东西可以如此直观地处理同步和异步通信。 —Jacinda Shelly,CTO,按需医生 Zulip提供了实时聊天的好处,同时还擅长异步通信。Zulip的灵感来自于电子邮件的高效线程模型:每个频道消息都有一个主题,就像电子邮件中的每个消息都有一个主题行一样。(频道在Zulip中称为流。) Zulip主题 主题将Zulip对话放在一起,就像主题行将电子邮件对话放在一起一样。它们使您可以有效地跟踪消息并在上下文中进行回复,甚至是数小时或数天之前开始的对话。 Zulip稍后回覆 它的概念很简单,但是从Slack切换到Zulip可以改变组织的通信方式: 领导者可以优先安排时间并批量回复消息,从而有效地参与聊天社区。 可以将更多讨论从会议和电子邮件转移到聊天。 各个贡献者可以做重点工作,而不是通过GIF进行分页,以确保他们不会错过任何重要的事情。 远程工作人员可以与在场人员平等地参与。 员工无需粘在键盘或电话上,以免错过重要的对话。 每个人都可以节省大量的时间和精力。

56,687

社区成员

发帖
与我相关
我的任务
社区描述
MySQL相关内容讨论专区
社区管理员
  • MySQL
加入社区
  • 近7日
  • 近30日
  • 至今
社区公告
暂无公告

试试用AI创作助手写篇文章吧