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
baiyi
V2EX  ›  MySQL

sql 语句优化求帮助

  •  
  •   baiyi ·
    cnbailian · 2016-07-13 17:59:04 +08:00 · 3903 次点击
    这是一个创建于 3061 天前的主题,其中的信息可能已经有所发展或是发生改变。

    项目有个需求 要用多个(目前测试为 1000 多)手机号去查找所属人员,where in () 里多达 1000 多个手机号,导致查询速度非常慢,有什么可以优化的地方吗

    27 条回复    2016-07-23 20:41:54 +08:00
    linauror
        1
    linauror  
       2016-07-13 18:05:04 +08:00   ❤️ 1
    加索引呢
    Volio
        2
    Volio  
       2016-07-13 18:05:47 +08:00   ❤️ 1
    手机号给个索引试试
    baiyi
        3
    baiyi  
    OP
       2016-07-13 18:06:04 +08:00
    @linauror 索引加了
    liprais
        4
    liprais  
       2016-07-13 18:09:31 +08:00   ❤️ 1
    把这 1000 多手机号建个表写进去,手机号建成主键 ,然后查询的时候 join 下
    hpeng
        5
    hpeng  
       2016-07-13 18:14:37 +08:00 via iPhone   ❤️ 1
    针对手机号函数索引。
    baiyi
        6
    baiyi  
    OP
       2016-07-13 19:50:45 +08:00
    跟同事讨论了下 觉得数据结构造成了这种查询语句是不科学的,而且还无法改变结构,索引也加了 效果不好,结贴了 想一想其他的方向
    harborM
        7
    harborM  
       2016-07-13 20:02:15 +08:00   ❤️ 1
    之前我的业务也做到一个 in 千量级的 sql 语句,也没什么办法
    loading
        8
    loading  
       2016-07-13 20:07:38 +08:00 via Android   ❤️ 1
    你数据库一共有多少条手机号码。
    baiyi
        9
    baiyi  
    OP
       2016-07-13 20:22:24 +08:00
    @loading 8000 多 需要从中拿 X 个去另外的表中 in 查询
    @harborM 是啊,在结构不能动的情况下,想不到什么办法
    loading
        10
    loading  
       2016-07-13 20:45:09 +08:00 via Android   ❤️ 1
    另一个表有多少条呢?
    hbprotoss
        11
    hbprotoss  
       2016-07-13 20:58:36 +08:00   ❤️ 1
    执行计划能放上来麽
    heaton_nobu
        12
    heaton_nobu  
       2016-07-13 22:20:58 +08:00   ❤️ 1
    用 join 会快很多
    realpg
        13
    realpg  
       2016-07-13 23:18:52 +08:00   ❤️ 1
    非常慢是多慢?
    jswh
        14
    jswh  
       2016-07-13 23:39:46 +08:00   ❤️ 1
    超长的 in 查询要么和上面网友说的一样用 join 的方式做交集,要么就直接接搜索引擎吧, sphinx 或者 elasticsearch
    fatpa
        15
    fatpa  
       2016-07-14 03:07:35 +08:00   ❤️ 1
    explain 看看 select 的结果先把
    ahm
        16
    ahm  
       2016-07-14 08:48:08 +08:00   ❤️ 1
    把一千个号码建个视图,然后用 left join 会不会快些呢
    ahm
        17
    ahm  
       2016-07-14 08:49:56 +08:00   ❤️ 1
    然后再号码上建立索引
    baiyi
        18
    baiyi  
    OP
       2016-07-14 09:30:34 +08:00
    感谢~
    目前进展是发现了 mysql5.7 能提高效率.从 9s 到 1.6s....
    Asan
        19
    Asan  
       2016-07-14 09:33:25 +08:00   ❤️ 1
    程序分批处理呢?
    baiyi
        20
    baiyi  
    OP
       2016-07-14 09:59:10 +08:00
    @Asan 程序分批处理感觉对于我们的结构来说不太可行
    Lao9
        21
    Lao9  
       2016-07-14 10:08:57 +08:00   ❤️ 1
    in-list ,就是构建数组跟基表进行类似索引联合的查询行为,这个依靠具体的数据库。如果没有类似功能、你可以自己手工实现类似的工作。否则数据库自己会去做这个事情无需操心
    shakusi
        22
    shakusi  
       2016-07-14 11:23:17 +08:00   ❤️ 1
    你这(目前测试为 1000 多)些号码有没有一些共同的规律,比如属于哪些段( 13700001001~13700002001 )这种,或者号码属于哪些区域,如果 where 条件后面加 in ,你的 SQL 语句不是也很长?
    能否换个思路,把 8000 条数据取出来,然后通过程序去过滤掉这 1000 条出来,比较下性能哪个更快?
    wander2008
        23
    wander2008  
       2016-07-14 11:25:32 +08:00 via iPhone   ❤️ 1
    in 里面 1000 多个值…
    billgreen1
        24
    billgreen1  
       2016-07-14 11:44:14 +08:00   ❤️ 1
    1. 把你的表结构贴出来
    2. 把你的 sql 语句贴出来

    按道理没这么慢的,我现在从 6million 中查 2000 个都在 0.0X 秒
    loading
        25
    loading  
       2016-07-14 12:34:49 +08:00 via Android   ❤️ 1
    居然是 9s ……不是语句有问题就是机器有问题
    baiyi
        26
    baiyi  
    OP
       2016-07-14 17:26:41 +08:00
    @Lao9 嗯,我去看一下
    @shakusi 并没有规律,过滤的话对于也不仅仅是 8000 条数据
    @loading 嗯 应该是语句的问题 感觉 mysql5.7 提升这么大是帮助优化语句了
    mingyun
        27
    mingyun  
       2016-07-23 20:41:54 +08:00
    @baiyi 线上数据库没那么容易直接升级吧
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   2414 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 25ms · UTC 01:00 · PVG 09:00 · LAX 17:00 · JFK 20:00
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.