MySQL查看表行数

引言

评估表规模、判断是否需要分表、统计数据量时都要看行数。COUNT(*)最准但大表慢，information_schema的TABLE_ROWS快但InnoDB是估算值，两个手段按场景选。

精确统计：COUNT(*)

SELECT COUNT(*) FROM users;

精确返回真实行数，MyISAM直接读元数据很快，InnoDB要逐行扫描，大表千万级以上会锁读、耗时长。

带条件统计

SELECT COUNT(*) FROM orders WHERE status = 1;

统计满足条件的行数，WHERE命中索引时走索引扫描，比全表快。

估算行数：information_schema

SELECT TABLE_NAME, TABLE_ROWS
FROM information_schema.TABLES
WHERE TABLE_SCHEMA = 'blog' AND TABLE_NAME = 'users';

秒出结果，适合先摸底表规模，但InnoDB的TABLE_ROWS是基于采样的估算值，可能和真实值差10%到20%。

一次查看库里所有表行数

SELECT TABLE_NAME, TABLE_ROWS, DATA_LENGTH/1024/1024 AS data_mb
FROM information_schema.TABLES
WHERE TABLE_SCHEMA = 'blog'
ORDER BY TABLE_ROWS DESC;

按行数排序，快速找出最大的几张表，配合DATA_LENGTH看占用空间。

大表COUNT优化思路

• 先看估算值判断量级，需要精确再COUNT；
• COUNT(*)走二级索引，别COUNT(主键)以外的可空字段；
• 历史归档、分表后单表控制在千万行以内；
• 实时统计用缓存或汇总表，不在线上大表直接COUNT。

注意事项

• InnoDB的COUNT(*)不加WHERE返回约数，精确值必须扫描；
• information_schema的TABLE_ROWS只是估算，别当准确值用于对账；
• 大表COUNT期间会产生一致性读，占用缓冲池，避开高峰；
• 表刚大量增删后元数据统计信息可能陈旧，先ANALYZE TABLE刷新；
• MyISAM的TABLE_ROWS是精确值，和InnoDB机制不同；
• 统计行数别用COUNT(1)和COUNT(*)纠结，性能基本一致。

总结

COUNT()精确统计行数，大InnoDB表慢且耗资源；information_schema.TABLE_ROWS秒出估算值用于摸底。先看估算判断表规模，需要精确再COUNT()，条件统计尽量走索引。大表COUNT避开业务高峰，增删数据后先ANALYZE TABLE刷新元数据。实时报表建议走汇总表或缓存，避免线上大表反复全表扫描。

MySQL删除数据库

引言

下线测试库、清理废弃项目时需要DROP DATABASE。这是高危操作，一旦执行库和所有表立即删除不可回滚，必须先确认库名、确认备份，避免误删生产库。

删除指定数据库

DROP DATABASE db_test;

删除整个库及其下所有表、视图、存储过程，磁盘空间立即释放。

库存在才删除

DROP DATABASE IF EXISTS db_test;

加IF EXISTS库不存在时不报错，脚本里更安全，避免中断。

删除前先确认

SHOW DATABASES LIKE 'db_test';
USE db_test;
SHOW TABLES;

先列出库和表，确认删的是目标库而不是同名生产库。

删除后验证

SHOW DATABASES;

库从列表消失即删除成功；磁盘空间由MySQL异步释放，大库可能需等一小会。

不要删错：先备份

mysqldump -u root -p db_test > /backup/db_test.sql

删除前先mysqldump导出，万一删错还能恢复。生产库删除前务必先备份再操作。

注意事项

• DROP DATABASE不可回滚，DELETE/TRUNCLE都比它温柔；
• 库名区分大小写（Linux下），别拼错；
• 需要DROP权限，普通业务账号不该有这个权限；
• 删除大库会锁实例一小段时间，高峰期别执行；
• 删除库不会自动删用户授权，残留grant需手动清理；
• 删库前确认无业务连接，可先停应用再删。

总结

DROP DATABASE删除整库，加IF EXISTS避免报错中断，删前用SHOW DATABASES确认目标、mysqldump先备份，删后再SHOW DATABASES验证。这是高危不可回滚操作，业务账号不应有DROP权限，删大库避开高峰期，删库后记得清理残留的用户授权。