Napisałem rozwiązanie tego zadania, ale nie jestem jedyną osobą, która zrobiła coś takiego.
select concat('`', table_schema, '`.`', table_name, '`.`', column_name, '`') as `column`,
auto_increment as `current_int`, max_int, round((auto_increment/max_int)*100, 2) as `pct_max`
from (select table_schema, table_name, column_name, auto_increment,
pow(2, case data_type
when 'tinyint' then 7
when 'smallint' then 15
when 'mediumint' then 23
when 'int' then 31
when 'bigint' then 63
end+(column_type like '% unsigned'))-1 as max_int
from information_schema.tables t
join information_schema.columns c using (table_schema,table_name)
join information_schema.key_column_usage k using (table_schema,table_name,column_name)
where t.table_schema in ('test')
and k.constraint_name = 'PRIMARY'
and k.ordinal_position = 1
and t.auto_increment is not null
) as dt;
https://github.com/billkarwin/bk -tools/blob/master/pk-full-ratio.sql
To zapytanie jest zakodowane na stałe dla test
schemat, więc musisz go edytować dla własnego schematu.
Krótka odpowiedź na pytanie „czy mój klucz podstawowy się przepełni?” to po prostu zmienić go na BIGINT UNSIGNED
Teraz. To z pewnością potrwa do upadku cywilizacji.
W tym samym repozytorium git mam inny podobny skrypt do sprawdzania wszystkich kolumny liczb całkowitych, a nie tylko klucze podstawowe z automatycznym przyrostem. Ale nie jest to tak bardzo niepokojące dla innych kolumn.