
自己写了个存储过程, 每天定时处理日志表, 需要一条一条去取. 主键 id 是 int 自增.
以前是这样的, 统计总数再用 limit 取
SELECT count(1) into count_sum from t_day_log_bak_1; SELECT x,x,x,x INTO @x,@x,@x,@x FROM t_day_log_bak_1 LIMIT ?,1; 改了之后是这样的, 获取最大的 id, 再去用 id 遍历.
SELECT max(id) into count_sum from t_day_log_bak_1; SELECT x,x,x,x INTO @x,@x,@x,@x FROM t_day_log_bak_1 where id = ?; 本地测试 10000 条数据, 时间从 35.352s 缩短到 11.212s.
然后我试了一天的数据, 总时间直接快了五倍...
1 husky 2017-06-28 14:45:13 +08:00 这意思是第一个没用索引,改了以后用了? |
2 johnny23 2017-06-28 14:50:22 +08:00 via iPhone 还是效率低 |
3 F281M6Dh8DXpD1g2 2017-06-28 14:50:40 +08:00 需要一条一条去遍历数据处理的需求一般都有更好的方法 |
7 F281M6Dh8DXpD1g2 2017-06-28 15:03:31 +08:00 @snail00 我没看到你遍历这些数据到底是要干啥 |
8 plusium 2017-06-28 15:28:18 +08:00 用游标会更快。搜索“ MySQL 游标”。 |
9 artandlol 2017-06-28 15:30:00 +08:00 类似 sql 查询缓慢出现率最高的一条。 如: select xx from xx limit 5000,1000 这个 SQL 每次都是全表扫描,建议添加 1 个自增 id 做索引,将 SQL 改为如下,可以提高处理速度 select xx from xx where id>5000 and id<6000; |
12 snail00 OP @artandlol #9 我就是这个问题, 查任务的时候发现这个任务锁了几十万行, 改了之后就不锁了, cpu 占用也下来了. |
20 0x8C 2017-06-28 18:19:21 +08:00 试试 tidb |
21 simple2025 2017-06-28 19:07:58 +08:00 via iPhone 感觉是 max 和 count 导致的 |