Mysql
 sql >> база данни >  >> RDS >> Mysql

E_WARNING:Грешка при изпращане на STMT_PREPARE пакет. PID=*

Re Slowlog:Покажете ни вашия my.cnf. Промените ли бяха в [mysqld] раздел? Тествайте го чрез SELECT SLEEP(12); , след което погледнете както във файла, така и в таблицата.

Алтернативен начин за намиране на заявката:Тъй като заявката отнема няколко минути, направете SHOW FULL PROCESSLIST; когато мислите, че може да работи.

Колко RAM имате? Не имат max_allowed_packet=300M освен ако нямате поне 30GB RAM. В противен случай рискувате да размените (или дори да се сринете). Запазете тази настройка под 1% от RAM.

За по-нататъшен анализ на настройките, моля, предоставете (1) размер на RAM, (2) SHOW VARIABLES; и (3) SHOW GLOBAL STATUS; .

Отново deleted_at :Тази връзка, която сте дали, започва с "Колоната deleted_at не е добър кандидат за индекс". Неправилно си го изтълкувал. Става дума за INDEX(deleted_at) с една колона . Предлагам съставен индекс като INDEX(contact_id, job_class_name, execute_at, deleted_at) .

158 секунди за проста заявка на малка маса? Възможно е да има много други случват се неща. Вземете PROCESSLIST .

Отново разделяне на индекси спрямо съставни:Помислете за два индекса:INDEX(last_name) и INDEX(first_name) . Прелиствате индекса на last_name, за да намерите "Джеймс", тогава какво можете да направите? Прелистването на другия указател за „Рик“ няма да ви помогне да ме намерите.

Анализ на ПРОМЕНИМИ и ГЛОБАЛНО СТАТУС

Наблюдения:

  • Версия:5.7.22-log
  • 1,00 GB RAM
  • Uptime =16d 10:30:19
  • Сигурни ли сте, че това беше ПОКАЗВАНЕ НА ГЛОБАЛНО СТАТУС?
  • Не работите под Windows.
  • Изпълнява се 64-битова версия
  • Изглежда, че използвате изцяло (или предимно) InnoDB.

По-важните проблеми:

innodb_buffer_pool_size -- Мислех, че го имаш на 213M, а не на 10M. 10M е много малко. От друга страна, изглежда, че имате по-малко от толкова много данни.

Тъй като RAM паметта е толкова малка, препоръчвам да намалите tmp_table_size и max_heap_table_size и max_allowed_packet до 8M. И намалете table_open_cache, table_definition_cache и innodb_open_files до 500.

Какво причинява толкова много едновременни връзки?

Подробности и други забележки:

( innodb_buffer_pool_size / _ram ) = 10M / 1024M = 0.98% -- % от RAM, използвана за InnoDB buffer_pool

( innodb_buffer_pool_size ) = 10M -- InnoDB данни + индексен кеш

( innodb_lru_scan_depth ) = 1,024 -- "InnoDB:page_cleaner:1000 ms планиран цикъл отне ..." може да се коригира чрез намаляване на lru_scan_depth

( Innodb_buffer_pool_pages_free / Innodb_buffer_pool_pages_total ) = 375 / 638 = 58.8% -- Pct на buffer_pool в момента не се използва-- innodb_buffer_pool_size е по-голям от необходимото?

( Innodb_buffer_pool_bytes_data / innodb_buffer_pool_size ) = 4M / 10M = 40.0% -- Процент от буферния пул, зает от данни -- Малък процент може показва, че buffer_pool е ненужно голям.

( innodb_log_buffer_size / _ram ) = 16M / 1024M = 1.6% -- Процент на RAM, използвана за буфериране на записите в регистрационните файлове в InnoDB.-- Твърде голям отнема от други употреби на RAM.

( innodb_log_file_size * innodb_log_files_in_group / innodb_buffer_pool_size ) = 48M * 2 / 10M = 960.0% -- Съотношение на размера на журнала към размера на buffer_pool. Препоръчва се 50%, но вижте други изчисления за това дали има значение.-- Не е необходимо регистрационният файл да е по-голям от буферния пул.

( innodb_flush_method ) = innodb_flush_method = -- Как InnoDB трябва да поиска от ОС да пише блокове. Предложете O_DIRECT или O_ALL_DIRECT (Percona), за да избегнете двойно буфериране. (Поне за Unix.) Вижте chrischandler за предупреждение относно O_ALL_DIRECT

( innodb_flush_neighbors ) = 1 -- Незначителна оптимизация при записване на блокове на диск.-- Използвайте 0 за SSD устройства; 1 за HDD.

( innodb_io_capacity ) = 200 - I/O операции в секунда, способни на диск. 100 за бавни задвижвания; 200 за въртящи се задвижвания; 1000-2000 за SSD дискове; умножете по RAID фактор.

( innodb_print_all_deadlocks ) = innodb_print_all_deadlocks = OFF -- Дали да се регистрират всички блокирания.-- Ако сте измъчвани от застой, включете това. Внимание:Ако имате много блокирания, това може да запише много на диска.

( min( tmp_table_size, max_heap_table_size ) / _ram ) = min( 16M, 16M ) / 1024M = 1.6% -- Процент RAM за разпределяне при нужда от таблица MEMORY (на таблица) или временна таблица в SELECT (за временна таблица за някои SELECT). Твърде високото може да доведе до размяна.-- Намалете tmp_table_size и max_heap_table_size до, да речем, 1% от ram.

( net_buffer_length / max_allowed_packet ) = 16,384 / 16M = 0.10%

( local_infile ) = local_infile = ON -- local_infile =ON е потенциален проблем със сигурността

( Select_scan / Com_select ) = 111,324 / 264144 = 42.1% -- % от избраните, извършващи пълно сканиране на таблицата. (Може да бъдете заблудени от Съхранени рутинни програми.)-- Добавяне на индекси/оптимизиране на заявки

( long_query_time ) = 10 -- Изрязване (секунди) за дефиниране на "бавна" заявка.-- Предложете 2

( Max_used_connections / max_connections ) = 152 / 151 = 100.7% -- Пиков % на връзките -- увеличете max_connections и/или намалете изчакване на изчакване

Имате половин изключен кеш на заявки. Трябва да зададете и query_cache_type =OFF и query_cache_size =0. Има (според слух) „бъг“ в QC кода, който оставя някакъв код включен, освен ако не изключите и двете настройки.

Необичайно малък:

( 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

Необичайно голям:

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

Ненормални низове:

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


  1. Database
  2.   
  3. Mysql
  4.   
  5. Oracle
  6.   
  7. Sqlserver
  8.   
  9. PostgreSQL
  10.   
  11. Access
  12.   
  13. SQLite
  14.   
  15. MariaDB
  1. MySQL Query не използва индекс в присъединяването на таблица

  2. Съхранение на динамични данни от формуляр в СУБД, търсене на оптимален подход

  3. MySQL Show Grants за всички потребители

  4. Грешка:mysqladmin:неуспешно обновяване; грешка:"Неизвестна грешка"

  5. ПРОМЕНЯНЕ НА ТАБЛИЦАТА