[SQL ] MySQL千萬筆資料Select很久

[oilolio (OG8)]

資料庫名稱：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://www.ptt.cc/bbs/Database/M.1550147086.A.B67.html
→ jojobill: Schema設計, config, GCP 機器規格, 這些資料都沒有,版
→ jojobill: 友需要強大的通靈能力才能知道發生什麼問題
抱歉已補上，如有不清楚再補感謝!
→ AndCycle: 以前接過連index都沒設定還上線了好幾年的爛案子 ...
※ 編輯: oilolio (220.135.52.190), 02/15/2019 00:18:35
※ 編輯: oilolio (220.135.52.190), 02/15/2019 00:19:20
→ jojobill: 所以你用MyISAM來跑嗎？ 因為你key_buffer_cache開了1G,
→ jojobill:  join_buffer, sort_buff 都是session base的, 你開1G完
→ jojobill: 全錯誤,直接抓掉這兩個設定吧. query_chche 請直接關了,
→ jojobill:  非常無用
→ jojobill: 正常來說使用InnoDB是比較常見的engine, 用到MyISAM 大
→ jojobill: 概都是當年預設直接上. Table 有pk嗎, index有開太多嗎
有開index, 有PK;所以是拿掉sort_buffer_size=128跟query_cache_size = 128M 這兩個嗎
※ 編輯: oilolio (111.251.158.148), 02/15/2019 15:40:10
→ jojobill: 當然沒這麼簡單,拿掉key_buffer_size = 1024M,sort_buff
→ jojobill: er_size = 128M,read_buffer_size = 128M. 只是回收無謂
→ jojobill: 浪費的memory, 問題的關鍵可能在innodb設定跟schema設計
→ et69523820: 我覺得關鍵是LIMIT 依你的描述一張表有超過千萬
→ et69523820: LIMIT 0,1000000 快
→ et69523820: LIMIT 30000000,1000000 慢
→ et69523820: LIMIT 500000,1000000 快
→ et69523820: 關鍵在於前面的數字 比如第二條規則
→ et69523820: 他是把資料庫讀取3千萬筆資料出來 在讀取一百萬
→ et69523820: 而不是指標訂在3千萬筆的點 在讀取一百萬
→ et69523820: 要想辦法把前面數字壓低
→ bestlong: 用EXPLAIN分析看看吧,沒有schema與SQL資訊,難解啊