V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
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
magicdu
V2EX  ›  MySQL

各位大佬,给看下 mysql 语句的问题

  •  
  •   magicdu ·
    magicdu · 2021-04-09 18:58:37 +08:00 · 2542 次点击
    这是一个创建于 1085 天前的主题,其中的信息可能已经有所发展或是发生改变。
    SELECT
    			factor_war,
    			warning_id
    		FROM
    			pes_warning_log_detail
    		WHERE
    			deptid = '517d16f720f7c6624cfb4245cc0586c0'
    

    这个语句查询十几秒,表数据量 50 多万,还能优化吗?不加 limit

    23 条回复    2021-04-10 17:09:05 +08:00
    rekulas
        1
    rekulas  
       2021-04-09 19:02:19 +08:00
    索引不正常吧 单字段查询 5 千万都不会这么慢
    zpfhbyx
        2
    zpfhbyx  
       2021-04-09 19:03:45 +08:00
    建个前缀索引?
    magicdu
        3
    magicdu  
    OP
       2021-04-09 19:05:30 +08:00
    ![QQ 图片 20210409190503]( https://tva1.sinaimg.cn/large/0065GZmcly1gpdp73d2uqj30zr04jmxg.jpg) @rekulas 索引是这样的
    RRRoger
        4
    RRRoger  
       2021-04-09 19:06:42 +08:00
    50w 单表查询不至于这么慢吧。

    确定加索引了?
    magicdu
        5
    magicdu  
    OP
       2021-04-09 19:07:58 +08:00
    @RRRoger 加了,是不是加的有问题 ,看下上面的图
    rekulas
        6
    rekulas  
       2021-04-09 19:11:10 +08:00
    重建索引试试?低版本 mysql 有可能索引失效 bug

    另外磁盘是什么型号,测试下,大概率磁盘导致
    ch2
        7
    ch2  
       2021-04-09 19:11:11 +08:00
    对 18W 行的结果十几秒不算慢吧
    wpblank
        8
    wpblank  
       2021-04-09 19:12:23 +08:00 via iPhone
    这个查询能查出 18w 条吗
    JasonLaw
        9
    JasonLaw  
       2021-04-09 19:13:19 +08:00   ❤️ 1
    1. 在这张表中,大概有 18 万行的 deptid = '517d16f720f7c6624cfb4245cc0586c0'(数据库估计出来的),所以索引在这中情况下是没有太大用处的。
    2. 索引虽然是顺序存储的,但是你 select 的 columns 在索引中不能找到,所以对于每个符合条件的行的主键,你都要去 primary index 中找出整行数据,但是这个时候,你会在 primary index 的东一个地方找,西一个地方找,磁盘 IO 超级严重。

    当然,这只是我通过你给的一些信息判断出来的,不一定对。
    sha851092391
        10
    sha851092391  
       2021-04-09 19:13:37 +08:00
    索引的 Cardinality 太低了,通过 deptid 查询匹配记录数太多。
    你的 SQL 匹配的记录快 20 万,不是有 limit 减少返回记录数,那就只能减少回表了,建立 deptid + factor_war + warning_id 的联合索引减少回表数看看。
    magicdu
        11
    magicdu  
    OP
       2021-04-09 19:13:47 +08:00
    查询 10 万条 @wpblank
    JasonLaw
        12
    JasonLaw  
       2021-04-09 19:15:45 +08:00
    @magicdu #3 顺便说一下,当 Cardinality 很小的情况下,建立索引是没有什么意义的。
    rekulas
        13
    rekulas  
       2021-04-09 19:16:52 +08:00
    50w 总数据 即使 18w 我觉得还是偏慢了 考虑磁盘性能不足

    作为对比 我测试下我这边的速度 2000w 数据表 查询 20w 记录的一个单字段 也不过才 2 秒左右
    jotpot
        14
    jotpot  
       2021-04-09 20:25:01 +08:00
    18w 的结果集? 想想都慢。磁盘要读,网络要传,客户端内存要加载,怎么不慢呢。话说你查 18w 出来干啥。
    ky11223344
        15
    ky11223344  
       2021-04-09 21:00:31 +08:00 via Android
    deptid 索引删了或者建个 deptid factor_war warning_id 的联合索引试试
    ikas
        16
    ikas  
       2021-04-09 21:34:46 +08:00
    这不是 sql 问题.........
    xuanbg
        17
    xuanbg  
       2021-04-09 22:00:27 +08:00
    把 18 万多条记录从数据库里面读出来传到你电脑上,十几秒不是很快了吗?
    securityCoding
        18
    securityCoding  
       2021-04-10 00:02:45 +08:00 via Android
    分页,带上上一次的游标
    SjwNo1
        19
    SjwNo1  
       2021-04-10 09:06:58 +08:00 via iPhone
    覆盖索引试一下 (话说也不至于这么慢吧,磁盘出问题了吧)
    hbolive
        20
    hbolive  
       2021-04-10 09:09:02 +08:00
    18 万的数据,这个时间正常。。
    rogerus
        21
    rogerus  
       2021-04-10 09:17:52 +08:00 via iPhone
    50 万行数据,一个 key 对应 18 万行。兄弟,你确定这是 sql 而不是表结构设计的问题吗?
    mazyi
        22
    mazyi  
       2021-04-10 16:27:59 +08:00
    联合索引试试,应该是回表导致变慢了
    qaqLjj
        23
    qaqLjj  
       2021-04-10 17:09:05 +08:00 via Android
    这个没法优化,加了联合索引估计也不会变快很多,你这个查的方式有问题,查询条件匹配的结果过多,而已没有 limit
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   我们的愿景   ·   实用小工具   ·   2795 人在线   最高记录 6543   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 26ms · UTC 11:54 · PVG 19:54 · LAX 04:54 · JFK 07:54
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.