MySQL 相关项目
? MariaDB
? Drizzle
参考文档
? http://mysql-python.sourceforge.net/MySQLdb.html
SELECT
factor_war,
warning_id
FROM
pes_warning_log_detail
WHERE
deptid = '517d16f720f7c6624cfb4245cc0586c0'
这个语句查询十几秒，表数据量 50 多万，还能优化吗？不加 limit
 |
1
rekulas 2021-04-09 19:02:19 +08:00
索引不正常吧 单字段查询 5 千万都不会这么慢
|
 |
2
zpfhbyx 2021-04-09 19:03:45 +08:00
建个前缀索引？
|
 |
3
magicdu OP  @rekulas 索引是这样的
|
 |
4
RRRoger 2021-04-09 19:06:42 +08:00
50w 单表查询不至于这么慢吧。
确定加索引了？ |
|
6
rekulas 2021-04-09 19:11:10 +08:00
重建索引试试？低版本 mysql 有可能索引失效 bug
另外磁盘是什么型号，测试下，大概率磁盘导致 |
 |
7
ch2 2021-04-09 19:11:11 +08:00
对 18W 行的结果十几秒不算慢吧
|
 |
8
wpblank 2021-04-09 19:12:23 +08:00 via iPhone
这个查询能查出 18w 条吗
|
 |
9
JasonLaw 2021-04-09 19:13:19 +08:00  1
1. 在这张表中，大概有 18 万行的 deptid = '517d16f720f7c6624cfb4245cc0586c0'（数据库估计出来的），所以索引在这中情况下是没有太大用处的。
2. 索引虽然是顺序存储的，但是你 select 的 columns 在索引中不能找到，所以对于每个符合条件的行的主键，你都要去 primary index 中找出整行数据，但是这个时候，你会在 primary index 的东一个地方找，西一个地方找，磁盘 IO 超级严重。 当然，这只是我通过你给的一些信息判断出来的，不一定对。 |
 |
10
sha851092391 2021-04-09 19:13:37 +08:00
索引的 Cardinality 太低了，通过 deptid 查询匹配记录数太多。
你的 SQL 匹配的记录快 20 万，不是有 limit 减少返回记录数，那就只能减少回表了，建立 deptid + factor_war + warning_id 的联合索引减少回表数看看。 |
|
13
rekulas 2021-04-09 19:16:52 +08:00
50w 总数据 即使 18w 我觉得还是偏慢了 考虑磁盘性能不足
作为对比 我测试下我这边的速度 2000w 数据表 查询 20w 记录的一个单字段 也不过才 2 秒左右 |
 |
14
jotpot 2021-04-09 20:25:01 +08:00
18w 的结果集？ 想想都慢。磁盘要读，网络要传，客户端内存要加载，怎么不慢呢。话说你查 18w 出来干啥。
|
 |
15
ky11223344 2021-04-09 21:00:31 +08:00 via Android
deptid 索引删了或者建个 deptid factor_war warning_id 的联合索引试试
|
 |
16
ikas 2021-04-09 21:34:46 +08:00
这不是 sql 问题.........
|
 |
17
xuanbg 2021-04-09 22:00:27 +08:00
把 18 万多条记录从数据库里面读出来传到你电脑上，十几秒不是很快了吗？
|
 |
18
securityCoding 2021-04-10 00:02:45 +08:00 via Android
分页，带上上一次的游标
|
 |
19
SjwNo1 2021-04-10 09:06:58 +08:00 via iPhone
覆盖索引试一下 （话说也不至于这么慢吧，磁盘出问题了吧）
|
 |
20
hbolive 2021-04-10 09:09:02 +08:00
18 万的数据，这个时间正常。。
|
 |
21
rogerus 2021-04-10 09:17:52 +08:00 via iPhone
50 万行数据，一个 key 对应 18 万行。兄弟，你确定这是 sql 而不是表结构设计的问题吗？
|
 |
22
mazyi 2021-04-10 16:27:59 +08:00
联合索引试试，应该是回表导致变慢了
|
 |
23
qaqLjj 2021-04-10 17:09:05 +08:00 via Android
这个没法优化，加了联合索引估计也不会变快很多，你这个查的方式有问题，查询条件匹配的结果过多，而已没有 limit
|
Select Language