สถานะทั่วโลก
MariaDB [(ไม่มี)]> แสดงสถานะทั่วโลก;
+--------------------------------------------- -------------+-------------------------------------- --------------+
| ชื่อตัวแปร | ค่า |
+--------------------------------------------- -------------+-------------------------------------- --------------+
| Aborted_clients | 10 |
| Aborted_connects | 17 |
| Access_denied_errors | 2808 |
| Acl_column_grants | 0 |
| Acl_database_grants | 255 |
| Acl_function_grants | 0 |
| Acl_procedure_grants | 0 |
| Acl_proxy_users | 1 |
| Acl_role_grants | 0 |
| Acl_roles | 0 |
| Acl_table_grants | 2 |
| Acl_users | 253 |
| Aria_pagecache_blocks_not_flushed | 0 |
| Aria_pagecache_blocks_unused | 15706 |
| Aria_pagecache_blocks_used | 40 |
| Aria_pagecache_read_requests | 287044 |
| Aria_pagecache_reads | 20253 |
| Aria_pagecache_write_requests | 36614 |
| Aria_pagecache_writes | 36593 |
| Aria_transaction_log_syncs | 1 |
| Binlog_commits | 0 |
| Binlog_group_commits | 0 |
| Binlog_group_commit_trigger_count | 0 |
| Binlog_group_commit_trigger_lock_wait | 0 |
| Binlog_group_commit_trigger_timeout | 0 |
| Binlog_snapshot_file | |
| Binlog_snapshot_position | 0 |
| Binlog_bytes_written | 0 |
| Binlog_cache_disk_use | 0 |
| Binlog_cache_use | 0 |
| Binlog_stmt_cache_disk_use | 0 |
| Binlog_stmt_cache_use | 0 |
| เวลาไม่ว่าง | 0.000000 |
| Bytes_received | 243371501 |
| Bytes_sent | 2355355672 |
| Com_admin_commands | 2293 |
| Com_alter_db | 0 |
| Com_alter_db_upgrade | 0 |
| Com_alter_event | 0 |
| Com_alter_function | 0 |
| Com_alter_procedure | 0 |
| Com_alter_server | 0 |
| Com_alter_table | 0 |
| Com_alter_tablespace | 0 |
| Com_alter_user | 0 |
| Com_analyze | 0 |
| Com_assign_to_keycache | 0 |
| Com_begin | 0 |
| Com_binlog | 0 |
| Com_call_procedure | 0 |
| Com_change_db | 92 |
| Com_change_master | 0 |
| Com_check | 0 |
| Com_checksum | 0 |
| คอม_คอมมิท | 0 |
| Com_compound_sql | 0 |
| Com_create_db | 0 |
| Com_create_event | 0 |
| Com_create_function | 0 |
| Com_create_index | 0 |
| Com_create_procedure | 0 |
| Com_create_role | 0 |
| Com_create_server | 0 |
| Com_create_table | 0 |
| Com_create_temporary_table | 0 |
| Com_create_trigger | 0 |
| Com_create_udf | 0 |
| Com_create_user | 0 |
| Com_create_view | 0 |
| Com_dealloc_sql | 0 |
| คอม_ลบ | 8354 |
| Com_delete_multi | 0 |
| คอม_โด | 0 |
| Com_drop_db | 0 |
| Com_drop_event | 0 |
| Com_drop_function | 0 |
| Com_drop_index | 0 |
| Com_drop_procedure | 0 |
| Com_drop_role | 0 |
| Com_drop_server | 0 |
| Com_drop_table | 0 |
| Com_drop_temporary_table | 0 |
| Com_drop_trigger | 0 |
| Com_drop_user | 0 |
| Com_drop_view | 0 |
| Com_empty_query | 0 |
| Com_execute_immediate | 0 |
| Com_execute_sql | 0 |
| คอม_ฟลัช | 0 |
| Com_get_diagnostics | 0 |
| Com_grant | 0 |
488 แถวในชุด (0.00 วินาที)
MariaDB [(ไม่มี)]>
my.cnf
[root@host ~]# cat /etc/my.cnf
#
# กลุ่มนี้ถูกอ่านทั้งโดยไคลเอ็นต์และเซิร์ฟเวอร์
# ใช้สำหรับตัวเลือกที่มีผลกับทุกสิ่ง
#
[ไคลเอ็นต์-เซิร์ฟเวอร์]
#
# รวมไฟล์ทั้งหมดจากไดเร็กทอรี config
#
!includedir /etc/my.cnf.d
[มายเอสคิวลด์]
log-error=/var/lib/mysql/s102.halabtech.net.err
ประสิทธิภาพสคีมา = 0
innodb_file_per_table=1
default-storage-engine=MyISAM
max_allowed_packet=268435456
open_files_limit=40000
ข้ามชื่อแก้ไข
sql_mode=''
local-infile = 0
connect_timeout=25
wait_timeout=30
interactive_timeout=30
แบบสอบถามช้าล็อก = 1
long_query_time=5
slow_query_log_file="/var/log/mysql-slow.log"
key_buffer_size = 128M
thread_stack = 128K
thread_cache_size = 8
max_heap_table_size = 256M
query_cache_limit = 4M
query_cache_size = 512M
innodb_buffer_pool_size = 2G
ข้อกำหนดเซิร์ฟเวอร์:
Intel(R) Core(TM) i7-8700 CPU @ 3.20GHz
หน่วยความจำ: 4107488k/68927488k พร้อมใช้งาน (รหัสเคอร์เนล 7792k, ขาด 1900528k, สงวนไว้ 1353716k, ข้อมูล 5950k, เริ่มต้น 1984k)
ขนาดระบบไฟล์ที่ใช้ Avail Use% Mounted on
devtmpfs 32G 0 32G 0% /การพัฒนา
tmpfs 32G 0 32G 0% /dev/shm
tmpfs 32G 28M 32G 1% /รัน
tmpfs 32G 0 32G 0% /sys/fs/cgroup
/dev/md2 437G 273G 142G 66% /
/dev/md1 488M 401M 62M 87% /บูต
tmpfs 6.3G 0 6.3G 0% /รัน/ผู้ใช้/0
tmpfs 6.3G 0 6.3G 0% /รัน/ผู้ใช้/987
tmpfs 6.3G 0 6.3G 0% /รัน/ผู้ใช้/1034
อัปเดต
การถ่ายโอนข้อมูลการค้นหาช้าของ MySQL: (เปลี่ยนชื่อจริงของฐานข้อมูล)
อ่านบันทึกการสืบค้น mysql ที่ช้าจาก /var/log/mysql-slow.log
จำนวน: 2 เวลา=20.58 วินาที (41 วินาที) ล็อก=0.00 วินาที (0 วินาที) Rows_sent=4089261.5 (8178523), Rows_examined=4089261.5 (8178523), Rows_affected=0.0 (0), root[root]@localhost
เลือก /*!40001 SQL_NO_CACHE */ * จาก `hb_udownloads`
จำนวน: 3 เวลา=15.38 วินาที (46 วินาที) ล็อค=0.00 วินาที (0 วินาที) Rows_sent=81.0 (243), Rows_examined=10026558.0 (30079674), Rows_affected=0.0 (0), เซิร์ฟเวอร์***_fusion[เซิร์ฟเวอร์***_fusion] @localhost
SELECT *,(เลือกจำนวน(id) จาก tbl_swkey
โดยที่ group_id=tbl_keygroup.id และ used=0) ขายแล้ว (เลือกจำนวน (id) จาก tbl_swkey
โดยที่ group_id=tbl_keygroup.id และ used=1) ตามที่ใช้จาก tbl_keygroup
เรียงลำดับตาม `displayorder` asc
จำนวน: 1 เวลา=8.68 วินาที (8 วินาที) ล็อก=0.00 วินาที (0 วินาที) Rows_sent=0.0 (0), Rows_examined=4090482.0 (4090482), Rows_affected=0.0 (0), support***_res[support***_res] @localhost
อัปเดต hb_udownloads SET `upackage_id` = 0 WHERE uppackage_id = 403775
จำนวน: 1 เวลา=5.64 วินาที (5 วินาที) ล็อก=0.00 วินาที (0 วินาที) Rows_sent=0.0 (0), Rows_examined=4088258.0 (4088258), Rows_affected=0.0 (0), support***_res[support***_res] @localhost
เลือก udownload_id เป็น retval จาก hb_udownloads โดยที่ user_id = 415064 และ file_id = 78499 LIMIT 1
จำนวน: 1 เวลา=5.58 วินาที (5 วินาที) ล็อก=0.00 วินาที (0 วินาที) Rows_sent=0.0 (0), Rows_examined=4088256.0 (4088256), Rows_affected=0.0 (0), support***_res[support***_res] @localhost
เลือก udownload_id เป็น retval จาก hb_udownloads โดยที่ user_id = 208286 และ file_id = 202629 LIMIT 1
จำนวน: 1 เวลา=5.35 วินาที (5 วินาที) ล็อก=0.00 วินาที (0 วินาที) Rows_sent=0.0 (0), Rows_examined=4088255.0 (4088255), Rows_affected=0.0 (0), support***_res[support***_res] @localhost
เลือก udownload_id เป็น retval จาก hb_udownloads โดยที่ user_id = 235082 และ file_id = 473624 LIMIT 1
จำนวน: 1 เวลา=5.21 วินาที (5 วินาที) ล็อก=0.00 วินาที (0 วินาที) Rows_sent=0.0 (0), Rows_examined=4088254.0 (4088254), Rows_affected=0.0 (0), support***_res[supporth***_res] @localhost
เลือก udownload_id เป็น retval จาก hb_udownloads โดยที่ user_id = 61350 และ file_id = 493488 LIMIT 1
จำนวน: 1 เวลา=5.17 วินาที (5 วินาที) ล็อก=0.00 วินาที (0 วินาที) Rows_sent=0.0 (0), Rows_examined=4088259.0 (4088259), Rows_affected=0.0 (0), support***_res[support***_res] @localhost
เลือก udownload_id เป็น retval จาก hb_udownloads โดยที่ user_id = 338554 และ file_id = 439150 LIMIT 1
ขอความกรุณาโปรดแนะนำว่าทำไมบางครั้งฉันถึงมีเดือยพุ่งสูงมากถึง 500% และควรทำอย่างไรเพื่อแก้ปัญหา เนื่องจากฉันได้รับข้อผิดพลาด 50x จำนวนมาก โปรดให้อภัยภาษาอังกฤษที่ไม่ดีของฉันด้วย ขอบคุณล่วงหน้า.
การใช้งาน CPU สูงมักจะหมายถึงการสแกนตารางในหน่วยความจำจำนวนมาก
ดูหนึ่งในข้อความค้นหาที่ช้าของคุณ:
เวลา=5.64 วินาที (5 วินาที) Rows_sent=0.0 (0) Rows_examined=4088258.0 (4088258)
เลือก udownload_id AS retval
จาก hb_udownloads
โดยที่ user_id = 415064
และ file_id = 78499
ขีดจำกัด 1
ข้อความค้นหากำลังอ่านตารางทั้งแถว 4M แต่กลับมามากที่สุด หนึ่ง ของพวกเขา (และในกรณีนี้ไม่มีเลย)
คุณต้องการ ดัชนี ในตารางนี้เพื่อรองรับการค้นหานี้ คอมโพสิตบน user_id และ file_id จะเป็นการเริ่มต้นที่ดี
นักฆ่าประสิทธิภาพอีกคนที่นี่:
เวลา=20.58 วินาที (41 วินาที) Rows_sent=4089261.5 (8178523) Rows_examined=4089261.5 (8178523)
เลือก /*!40001 SQL_NO_CACHE */ *
จาก `hb_udownloads`
ไม่เคยใช้ "เลือก *" ในรหัสการผลิต
เสมอ ระบุคอลัมน์ที่คุณต้องการอย่างชัดเจน ฉันเดาว่าตารางนี้ "เติบโต" (ได้รับคอลัมน์) เมื่อเร็ว ๆ นี้
ตกลง หากไม่มี where clause นี่จะเป็นการสแกนตารางอยู่ดี แต่นั่นทำให้เกิดคำถาม - ไคลเอ็นต์ที่ไม่ดี [แอปพลิเคชัน] จะไปทำอะไร ทำ ด้วยแถว 4M ที่ข้อความค้นหานี้ "โยน" ไปที่มัน
บางส่วนของข้อความค้นหาเหล่านี้ดูเหมือนว่าอาจต้องมีการเพิ่มประสิทธิภาพ
ตัวอย่างเช่น:
Rows_examined=10026558.0 (30079674), Rows_affected=0.0 (0), เซิร์ฟเวอร์***_fusion[เซิร์ฟเวอร์***_fusion]@localhost
SELECT *,(เลือกจำนวน(id) จาก tbl_swkey
โดยที่ group_id=tbl_keygroup.id และ used=0) ขายแล้ว (เลือกจำนวน (id) จาก tbl_swkey
โดยที่ group_id=tbl_keygroup.id และ used=1) ตามที่ใช้จาก tbl_keygroup
เรียงลำดับตาม `displayorder` asc
ข้อความค้นหานี้กำลังสแกน 30000000 แถว
คุณสามารถเปลี่ยนสิ่งนี้ได้ เช่น เป็นสองข้อความค้นหา:
เลือก * จาก tbl_keygroup ORDER โดย `displayorder` asc;
เลือกจำนวน (id) จาก tbl_swkey ที่ใช้ใน (0,1) GROUP BY ใช้;
เนื่องจากแบบสอบถามนั้นเกี่ยวข้องกับการเข้าร่วมที่ไม่มีประโยชน์และการสแกนตารางแบบเต็มสองรายการที่อาจลดลงครึ่งหนึ่ง
สิ่งที่คุณแสดงส่วนใหญ่ชี้ให้เห็นถึงปัญหาเกี่ยวกับการเพิ่มประสิทธิภาพการสืบค้น และฉันจะดูบันทึกการสืบค้นที่ช้านั้นเพื่อพิจารณาว่าวิธีใดที่ดีที่สุดในการดึงข้อมูลนั้นด้วยการสแกนตารางให้น้อยที่สุด
คุณอาจต้องการจัดทำดัชนีข้อมูลจำนวนมากด้วยเพื่อจุดประสงค์เดียวกัน
** สิ่งนี้จะทำให้อันแรกเร็วขึ้นมาก:
เลือก k.*, s.sold, s.used
จาก ( เลือก group_id,
SUM(ใช้แล้ว = 0) ตามที่ขาย
SUM(ใช้แล้ว = 1) AS ใช้แล้ว
จาก tbl_swkey
) AS s
เข้าร่วม tbl_keygroup AS k บน s.group_id = k.id
ORDER BY แสดงคำสั่ง
และมี
tbl_swkey: INDEX (group_id, ใช้แล้ว)
tbl_keygroup: INDEX (ลำดับการแสดง)
หากคุณต้องการหารือเกี่ยวกับคำถามนี้เพิ่มเติม โปรดระบุ แสดงการสร้างตาราง สำหรับทั้งตาราง ขนาดตาราง และ อธิบายการเลือก ....
** นี้
เลือก udownload_id AS retval
จาก hb_udownloads
โดยที่ user_id = 415064
และ file_id = 78499
ขีดจำกัด 1
ต้องการดัชนีคอมโพสิต 3 คอลัมน์เพื่อให้เร็วขึ้นมาก:
INDEX(user_id, file_id, udownload_id)
คุณไม่สนใจว่าคุณจะได้แถวไหนที่ตรงกัน? หรือควรเพิ่ม สั่งโดย? หากคุณเพิ่มไฟล์ สั่งโดยคำแนะนำดัชนีของฉันอาจต้องเปลี่ยน
**สิ่งนี้มาจาก mysqldump?
เลือก /*!40001 SQL_NO_CACHE */ * จาก `hb_udownloads`
หากคุณไม่พอใจกับการบุกรุกของการถ่ายโอนข้อมูล มีการสนทนามากมายเกี่ยวกับหัวข้อนั้นใน dba.stackexchange.com
คนส่วนใหญ่ไม่เข้าใจว่าการถามคำถามมากมายจะปลดล็อกการเรียนรู้และปรับปรุงความสัมพันธ์ระหว่างบุคคล ตัวอย่างเช่น ในการศึกษาของ Alison แม้ว่าผู้คนจะจำได้อย่างแม่นยำว่ามีคำถามกี่ข้อที่ถูกถามในการสนทนา แต่พวกเขาไม่เข้าใจความเชื่อมโยงระหว่างคำถามและความชอบ จากการศึกษาทั้ง 4 เรื่องที่ผู้เข้าร่วมมีส่วนร่วมในการสนทนาด้วยตนเองหรืออ่านบันทึกการสนทนาของผู้อื่น ผู้คนมักไม่ตระหนักว่าการถามคำถามจะมีอิทธิพลหรือมีอิทธิพลต่อระดับมิตรภาพระหว่างผู้สนทนา
