作者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/m.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