必须显式确认并配置innodb_file_per_table才真正生效：先执行SELECT @@innodb_file_per_table;或SHOW VARIABLES LIKE 'innodb_file_per_table';查值，返回1或ON才启用；需在[mysqld]段配置文件中设innodb_file_per_table=ON并重启MySQL，否则动态设置仅对新表生效且老表仍留在ibdata1。
innodb_file_per_table 必须显式启用才真正生效，MySQL 8.0+ 虽默认为 ON，但若初始化时跳过配置文件或用 --initialize-insecure，仍可能为 OFF；不查就开干，容易误判。
怎么确认当前是否已启用 innodb_file_per_table
别靠猜或看版本，直接查变量值：
-
SELECT @@innodb_file_per_table;—— 返回1表示已启用，0表示关闭 -
SHOW VARIABLES LIKE 'innodb_file_per_table';—— 查看Value列是ON还是OFF
注意：即使返回 ON，也得检查是否写在配置文件里。动态设置（如 SET GLOBAL innodb_file_per_table = ON;）只对后续新建表生效，且 MySQL 5.6 及更早版本不支持该动态修改。
在哪改、怎么改才永久生效
必须编辑 MySQL 配置文件（如 /etc/my.cnf 或 /etc/mysql/mysql.conf.d/mysqld.cnf），且严格放在 [mysqld] 段下：
- 加一行：
innodb_file_per_table = ON（MySQL 5.6+ 推荐用ON，旧版也认1） - 绝不能写在
[client]、[mysql]或其他段里，否则无效 - 改完必须重启 MySQL 实例：
systemctl restart mysql或service mysqld restart
重启后再次查变量，确保值稳定为 ON —— 否则说明配置没加载成功（常见于路径错、段名错、语法错）。
Pandas 配置文件报告生成器
下载
使用ydata-profiling（前身为pandas-profiling）生成全面的数据质量报告，包含相关性分析、缺失值模式和基数检测。导出交互式HTML仪表板和JSON摘要。
开了之后老表还在 ibdata1 里，怎么办
启用 innodb_file_per_table 不会自动迁移已有表，这是最常被忽略的事实：
- 新创建的表会生成独立
.ibd文件，路径在数据目录下对应数据库子目录中 - 已有表仍留在共享表空间
ibdata1中，删表也不释放磁盘空间 - 要让老表“搬出来”，必须重建：
ALTER TABLE your_table ENGINE=InnoDB; - 该操作会锁表（除非用
pt-online-schema-change或 MySQL 5.6+ 的在线 DDL），执行后检查对应目录是否有your_table.ibd
重建后若仍没 .ibd，可能是表引擎不是 InnoDB（查 SHOW CREATE TABLE your_table; 确认 ENGINE=InnoDB）。
删表后磁盘空间没释放？先排查这几个点
即使开了 innodb_file_per_table，删表不回收空间也很常见，原因往往不在配置本身：
- Linux 文件系统层未释放：
mysqld进程仍持有已删.ibd的文件句柄，需重启 MySQL 或等其自动释放（lsof -p $(pgrep mysqld) | grep deleted可验证） -
.ibd文件残留：手动删了.frm却漏删.ibd，或反向操作，导致元数据与物理文件状态不一致 - 真正占空间的是 undo 表空间（如
undo_001），尤其当innodb_undo_log_truncate=ON但收缩失败时 -
ibdata1无法收缩：哪怕所有表都迁出，只要它曾被写入过，就只能增长不能缩小；彻底清理只能导出 → 清库 → 重建 → 导入
真正麻烦的是混合状态：部分表在 .ibd，部分还在 ibdata1 —— 此时 ibdata1 永远卡在最大历史体积，删再多独立表也没用。
