84669 人が学習中
152542 人が学習中
20005 人が学習中
5487 人が学習中
7821 人が学習中
359900 人が学習中
3350 人が学習中
180660 人が学習中
48569 人が学習中
18603 人が学習中
40936 人が学習中
1549 人が学習中
1183 人が学習中
32909 人が学習中
mysql查询,滤除某一字段packageId(不是主键) = num的结果,是直接使用not in 好还是查询完毕遍历结果集的时候滤除好。查询完后无论怎样都需要遍历结果集。
第一种更快。mysql查询速度要远快于遍历的速度的。遍历的时候循环次数越少越好。
题主在评论中补充了问题
就是考虑到索引,所以才会考虑这类查询条件会不走索引,全表查询速率会很慢。不过这个任务的数据量还是很大的。这个是给网站的一些套餐用户发送短信的提醒的功能。不等于7是因为这个套餐是免费送的,不在考虑的范围内。所以又必须去除。
对于这种大数据量的全表遍历, 首先这种全表取的方式就是不可取的, 你可以考虑通过主键id分段的形式来进行查询, 比如说, 你第一次查询 id > 0 的200条记录, 然后记录下最大id, 然后再查询 > 当前最大id的200条记录, 以此类推
在配合这种id分段的场景下, 你可以放心的把你的packageId放入查询条件, 因为肯定是走到主键id上去的, 所以mysql过滤的数据最多也就200条, 所以问题不大 (200只是举例, 你可以自己根据实际情况和服务压力进行控制)
额外还带来一个好处是你也可以实时观察当前任务的进行情况(发送了200个用户了你可以打个日志, 如果中断你也可以知道从哪里开始)
==== 以下是原答案 ===
你这个查询是没有分页的, 这里也就假定你的数据量其实非常小. 然后因为没有分页也必然会有全表扫描, 直接在sql查询时做掉好了, 没啥太大差别另外, 只是单纯的不等于一个值, 用 != 更加直观
如果你的查询是数据量有一点规模的, 或者其实是有分页的(只是你这里的演示代码还没写出来), 那么你应该要考虑是否有其它的带索引的查询条件来辅助你查询到你的数据, 如果没有, 那你需要考虑对于这个packageId也要考虑一下是否要加索引 (如果packageId的分布在这个表中足够分散)
第一种更快。mysql查询速度要远快于遍历的速度的。遍历的时候循环次数越少越好。
题主在评论中补充了问题
就是考虑到索引,所以才会考虑这类查询条件会不走索引,全表查询速率会很慢。不过这个任务的数据量还是很大的。这个是给网站的一些套餐用户发送短信的提醒的功能。不等于7是因为这个套餐是免费送的,不在考虑的范围内。所以又必须去除。
对于这种大数据量的全表遍历, 首先这种全表取的方式就是不可取的, 你可以考虑通过主键id分段的形式来进行查询, 比如说, 你第一次查询 id > 0 的200条记录, 然后记录下最大id, 然后再查询 > 当前最大id的200条记录, 以此类推
在配合这种id分段的场景下, 你可以放心的把你的packageId放入查询条件, 因为肯定是走到主键id上去的, 所以mysql过滤的数据最多也就200条, 所以问题不大 (200只是举例, 你可以自己根据实际情况和服务压力进行控制)
额外还带来一个好处是你也可以实时观察当前任务的进行情况(发送了200个用户了你可以打个日志, 如果中断你也可以知道从哪里开始)
==== 以下是原答案 ===
你这个查询是没有分页的, 这里也就假定你的数据量其实非常小. 然后因为没有分页也必然会有全表扫描, 直接在sql查询时做掉好了, 没啥太大差别
另外, 只是单纯的不等于一个值, 用 != 更加直观
如果你的查询是数据量有一点规模的, 或者其实是有分页的(只是你这里的演示代码还没写出来), 那么你应该要考虑是否有其它的带索引的查询条件来辅助你查询到你的数据, 如果没有, 那你需要考虑对于这个packageId也要考虑一下是否要加索引 (如果packageId的分布在这个表中足够分散)