Re Slowlog:Cho chúng tôi xem my.cnf của bạn. Có phải là những thay đổi trong [mysqld] tiết diện? Kiểm tra nó qua SELECT SLEEP(12); , sau đó xem cả tệp và bảng.
Cách thay thế để tìm truy vấn:Vì truy vấn mất vài phút, hãy thực hiện SHOW FULL PROCESSLIST; khi bạn nghĩ rằng nó có thể đang chạy.
Bạn có bao nhiêu RAM? Đ ừng có max_allowed_packet=300M trừ khi bạn có ít nhất 30GB RAM. Nếu không, bạn đang mạo hiểm hoán đổi (hoặc thậm chí gặp sự cố). Giữ cài đặt đó dưới 1% RAM.
Để phân tích sâu hơn về các câu cá ngừ, vui lòng cung cấp (1) kích thước RAM, (2) SHOW VARIABLES; và (3) SHOW GLOBAL STATUS; .
Re deleted_at :Liên kết mà bạn đã đưa ra bắt đầu bằng "Cột xóa_at không phải là một ứng cử viên chỉ mục tốt". Bạn đã hiểu sai về nó. Nó đang nói về một cột đơn INDEX(deleted_at) . Tôi đang đề xuất một chỉ mục tổng hợp chẳng hạn như INDEX(contact_id, job_class_name, execute_at, deleted_at) .
158 giây cho một truy vấn đơn giản trên một bảng nhỏ? Có thể là có rất nhiều khác những thứ đang diễn ra. Nhận PROCESSLIST .
Tách lại các chỉ mục so với tổng hợp:Hãy nghĩ đến hai chỉ mục:INDEX(last_name) và INDEX(first_name) . Bạn lướt qua chỉ mục last_name để tìm "James", sau đó bạn có thể làm gì? Lật qua chỉ mục khác cho "Rick" sẽ không giúp bạn tìm thấy tôi.
Phân tích BIẾN TẦN và TRẠNG THÁI TOÀN CẦU
Quan sát:
- Phiên bản:5.7.22-log
- 1,00 GB RAM
- Thời gian hoạt động =16 ngày 10:30:19
- Bạn có chắc đây là TRẠNG THÁI TOÀN CẦU HIỂN THỊ không?
- Bạn không chạy trên Windows.
- Đang chạy phiên bản 64 bit
- Có vẻ như bạn đang chạy hoàn toàn (hoặc hầu hết) InnoDB.
Các vấn đề quan trọng hơn:
innodb_buffer_pool_size - Tôi nghĩ rằng bạn có nó ở mức 213 triệu, không phải 10 triệu. 10M là quá nhỏ. Mặt khác, dường như bạn có ít dữ liệu hơn nhiều.
Vì RAM quá nhỏ, tôi khuyên bạn nên giảm tmp_table_size và max_heap_table_size và max_allowed_packet xuống 8M. Và thấp hơn table_open_cache, table_definition_cache và innodb_open_files xuống 500.
Điều gì gây ra quá nhiều kết nối đồng thời?
Chi tiết và các quan sát khác:
( innodb_buffer_pool_size / _ram ) = 10M / 1024M = 0.98% -% RAM được sử dụng cho InnoDB buffer_pool
( innodb_buffer_pool_size ) = 10M - Bộ nhớ cache chỉ mục + Dữ liệu InnoDB
( innodb_lru_scan_depth ) = 1,024 - "InnoDB:page_cleaner:1000ms vòng lặp dự định mất ..." có thể được khắc phục bằng cách hạ thấp lru_scan_depth
( Innodb_buffer_pool_pages_free / Innodb_buffer_pool_pages_total ) = 375 / 638 = 58.8% - Pct của buffer_pool hiện không được sử dụng - innodb_buffer_pool_size lớn hơn mức cần thiết?
( Innodb_buffer_pool_bytes_data / innodb_buffer_pool_size ) = 4M / 10M = 40.0% - Phần trăm vùng đệm bị chiếm dụng bởi dữ liệu-- Một phần trăm nhỏ có thể cho biết rằng buffer_pool lớn không cần thiết.
( innodb_log_buffer_size / _ram ) = 16M / 1024M = 1.6% - Phần trăm RAM được sử dụng để đệm ghi nhật ký InnoDB. - Quá lớn sẽ làm mất đi các mục đích sử dụng khác của RAM.
( innodb_log_file_size * innodb_log_files_in_group / innodb_buffer_pool_size ) = 48M * 2 / 10M = 960.0% - Tỷ lệ giữa kích thước nhật ký với kích thước vùng đệm. 50% được khuyến nghị, nhưng hãy xem các tính toán khác để biết liệu nó có quan trọng hay không. - Nhật ký không cần lớn hơn vùng đệm.
( innodb_flush_method ) = innodb_flush_method = - Cách InnoDB nên yêu cầu HĐH viết các khối. Đề xuất O_DIRECT hoặc O_ALL_DIRECT (Percona) để tránh đệm kép. (Ít nhất là đối với Unix.) Xem chrischandler để biết thông báo trước về O_ALL_DIRECT
( innodb_flush_neighbors ) = 1 - Một tối ưu hóa nhỏ khi ghi các khối vào đĩa. - Sử dụng 0 cho ổ SSD; 1 cho ổ cứng.
( innodb_io_capacity ) = 200 - I / O ops mỗi giây có khả năng trên đĩa. 100 cho ổ đĩa chậm; 200 cho ổ quay; 1000-2000 cho SSD; nhân với hệ số RAID.
( innodb_print_all_deadlocks ) = innodb_print_all_deadlocks = OFF - Có đăng nhập tất cả các Deadlocks hay không. - Nếu bạn gặp khó khăn với Deadlock, hãy bật tính năng này. Thận trọng:Nếu bạn có nhiều bế tắc, điều này có thể ghi nhiều vào đĩa.
( min( tmp_table_size, max_heap_table_size ) / _ram ) = min( 16M, 16M ) / 1024M = 1.6% - Phần trăm RAM để phân bổ khi cần bảng MEMORY (mỗi bảng), hoặc bảng tạm thời bên trong một SELECT (mỗi bảng tạm trên một số SELECT). Quá cao có thể dẫn đến hoán đổi. - Giảm tmp_table_size và max_heap_table_size, chẳng hạn như 1% ram.
( net_buffer_length / max_allowed_packet ) = 16,384 / 16M = 0.10%
( local_infile ) = local_infile = ON - local_infile =ON là một vấn đề bảo mật tiềm ẩn
( Select_scan / Com_select ) = 111,324 / 264144 = 42.1% -% lựa chọn thực hiện quét toàn bộ bảng. (Có thể bị đánh lừa bởi Quy trình lưu trữ.) - Thêm chỉ mục / tối ưu hóa truy vấn
( long_query_time ) = 10 - Thời gian cắt (Giây) để xác định truy vấn "chậm". - Đề xuất 2
( Max_used_connections / max_connections ) = 152 / 151 = 100.7% -% kết nối cao nhất - tăng max_connections và / hoặc giảm wait_timeout
Bạn đã tắt bộ nhớ cache truy vấn. Bạn nên đặt cả query_cache_type =OFF và query_cache_size =0. Có (theo tin đồn) có 'lỗi' trong mã QC khiến một số mã vẫn bật trừ khi bạn tắt cả hai cài đặt đó.
Nhỏ bất thường:
( Innodb_pages_read + Innodb_pages_written ) / Uptime = 0.186
Created_tmp_files = 0.015 /HR
Handler_write = 0.21 /sec
Innodb_buffer_pool_bytes_data = 3 /sec
Innodb_buffer_pool_pages_data = 256
Innodb_buffer_pool_pages_total = 638
Key_reads+Key_writes + Innodb_pages_read+Innodb_pages_written+Innodb_dblwr_writes+Innodb_buffer_pool_pages_flushed = 0.25 /sec
Table_locks_immediate = 2.8 /HR
Table_open_cache_hits = 0.44 /sec
innodb_buffer_pool_chunk_size = 5MB
Lớn bất thường:
Com_create_db = 0.41 /HR
Com_drop_db = 0.41 /HR
Connection_errors_peer_address = 2
Performance_schema_file_instances_lost = 9
Ssl_default_timeout = 500
Chuỗi bất thường:
ft_boolean_syntax = + -><()~*:&
have_ssl = YES
have_symlink = DISABLED
innodb_fast_shutdown = 1
optimizer_trace = enabled=off,one_line=off
optimizer_trace_features = greedy_search=on, range_optimizer=on, dynamic_range=on, repeated_subselect=on
session_track_system_variables = time_zone, autocommit, character_set_client, character_set_results, character_set_connection
slave_rows_search_algorithms = TABLE_SCAN,INDEX_SCAN
