MySQL 5.5 Community Server MySQL 5.6 Community Server Percona Configuration Wizard XtraBackup 搭建主从复制 Great Sites on MySQL Percona MySQL Performance Blog Severalnines 推荐管理工具 Sequel Pro phpMyAdmin 推荐书目 MySQL Cookbook
MySQL 相关项目 MariaDB Drizzle 参考文档 http://mysql-python.sourceforge.net/MySQLdb.html
MySQL 相关项目 MariaDB Drizzle 参考文档 http://mysql-python.sourceforge.net/MySQLdb.html 
这是一个创建于 1696 天前的主题，其中的信息可能已经有所发展或是发生改变。
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 justseemore 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 的联合索引减少回表数看看。 |
| img src="https://cdn.v2ex.com/gravatar/4fdf59ece7cd78f432ec513634889579?s=48&d=retro" class="avatar" border="0" align="default" alt="JasonLaw" data-uid="484411" /> | 12 JasonLaw 2021-04-09 19:15:45 +08:00 @magicdu #3 顺便说一下，当 Cardinality 很小的情况下，建立索引是没有什么意义的。 |
| 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 PRO 联合索引试试，应该是回表导致变慢了 |
 | 23 MarkLazy 2021-04-10 17:09:05 +08:00 via Android 这个没法优化，加了联合索引估计也不会变快很多，你这个查的方式有问题，查询条件匹配的结果过多，而已没有 limit |
Select Language