作者oilolio (OG8)
看板Database
标题[SQL ] MySQL千万笔资料Select很久
时间Thu Feb 14 20:24:44 2019
资料库名称：MySQL
资料库版本：5.5.60
内容/问题描述：
想请问各位版上大神，小弟资料库有几个table资料数超过百万，更有三四个超过
三四千万还在持续长大，使用GCP的主机8核16G记忆体，先不论程式码或SQL语句优化
目前光是一般的Select不加任何Where条件，LIMIT一百万笔出来就需要花上一分钟以上
，三四千万的table直接卡住，请问是config档没有设定好吗?有哪些设定最主要影响的吗?
google到的设定改了之後都无感，但两三百万笔的资料搜寻会需要这麽久吗?
有劳各位大神指点迷津了!
----- 补一下 -----
*GCP:
CentOS7 8核心CPU 16G记忆体
*Schema:
Engine InnoDB
*MySQL config:
[mysqld]
port = 3306
socket = /var/lib/mysql/mysql.sock
skip-locking
key_buffer_size = 1024M
max_allowed_packet = 32M
table_open_cache = 512
sort_buffer_size = 128M
read_buffer_size = 128M
read_rnd_buffer_size = 8M
myisam_sort_buffer_size = 128M
thread_cache_size = 16
query_cache_size = 128M
thread_concurrency = 8
innodb_file_per_table = 1
[mysqldump]
quick
max_allowed_packet = 16M
[mysql]
no-auto-rehash
[myisamchk]
key_buffer_size = 256M
sort_buffer_size = 256M
read_buffer = 2M
write_buffer = 2M
[mysqlhotcopy]
interactive-timeout
--
※ 发信站: 批踢踢实业坊(ptt.cc), 来自: 220.135.52.190
※ 文章网址: https://webptt.com/cn.aspx?n=bbs/Database/M.1550147086.A.B67.html
1F：→ jojobill: Schema设计, config, GCP 机器规格, 这些资料都没有,版 02/14 22:19
2F：→ jojobill: 友需要强大的通灵能力才能知道发生什麽问题 02/14 22:19
抱歉已补上，如有不清楚再补感谢!
3F：→ AndCycle: 以前接过连index都没设定还上线了好几年的烂案子 ... 02/14 23:40
※ 编辑: oilolio (220.135.52.190), 02/15/2019 00:18:35
※ 编辑: oilolio (220.135.52.190), 02/15/2019 00:19:20
4F：→ jojobill: 所以你用MyISAM来跑吗？ 因为你key_buffer_cache开了1G, 02/15 08:19
5F：→ jojobill: join_buffer, sort_buff 都是session base的, 你开1G完 02/15 08:19
6F：→ jojobill: 全错误,直接抓掉这两个设定吧. query_chche 请直接关了, 02/15 08:19
7F：→ jojobill: 非常无用 02/15 08:20
8F：→ jojobill: 正常来说使用InnoDB是比较常见的engine, 用到MyISAM 大 02/15 08:26
9F：→ jojobill: 概都是当年预设直接上. Table 有pk吗, index有开太多吗 02/15 08:26
有开index, 有PK;所以是拿掉sort_buffer_size=128跟query_cache_size = 128M 这两个吗
※ 编辑: oilolio (111.251.158.148), 02/15/2019 15:40:10
10F：→ jojobill: 当然没这麽简单,拿掉key_buffer_size = 1024M,sort_buff 02/16 09:15
11F：→ jojobill: er_size = 128M,read_buffer_size = 128M. 只是回收无谓 02/16 09:15
12F：→ jojobill: 浪费的memory, 问题的关键可能在innodb设定跟schema设计 02/16 09:15
13F：→ et69523820: 我觉得关键是LIMIT 依你的描述一张表有超过千万 02/20 03:49
14F：→ et69523820: LIMIT 0,1000000 快 02/20 03:49
15F：→ et69523820: LIMIT 30000000,1000000 慢 02/20 03:49
16F：→ et69523820: LIMIT 500000,1000000 快 02/20 03:49
17F：→ et69523820: 关键在於前面的数字 比如第二条规则 02/20 03:50
18F：→ et69523820: 他是把资料库读取3千万笔资料出来 在读取一百万 02/20 03:50
19F：→ et69523820: 而不是指标订在3千万笔的点 在读取一百万 02/20 03:50
20F：→ et69523820: 要想办法把前面数字压低 02/20 03:50
21F：→ bestlong: 用EXPLAIN分析看看吧,没有schema与SQL资讯,难解啊 03/21 19:04