MySQL 8.0+中会话级隔离级别须在事务开始前设置，全局级修改需配置文件重启才永久生效；所有修改必须避开活跃事务，且值必须用短横线格式（如READ-COMMITTED）。
MySQL 8.0+ 中，会话级隔离级别可随时动态修改，但全局级在运行时只能通过 SET GLOBAL 临时生效（部分版本已限制），永久生效必须改配置文件并重启；且所有修改都必须避开活跃事务。
会话级修改：必须在事务开始前执行
一旦当前连接已处于事务中（@@in_transaction 返回 1），任何 SET SESSION TRANSACTION ISOLATION LEVEL 都会报错：Can't change transaction isolation level when a transaction is active。
- 先检查状态：
SELECT @@in_transaction;，若为 1，必须先COMMIT或ROLLBACK - 推荐写法（任选其一）：
SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED;、SET TRANSACTION ISOLATION LEVEL REPEATABLE READ;（SESSION可省略） - 错误写法示例：
SET SESSION tx_isolation = 'READ-COMMITTED';（tx_isolation在 8.0+ 已废弃）、SET @@transaction_isolation = 'READ-COMMITTED';（语法非法） - 值必须用短横线（
READ-COMMITTED），不能用下划线（READ_COMMITTED）或空格分隔后不加引号
全局级修改：运行时 SET GLOBAL 有限制，8.0+ 多数场景需配文件重启
SET GLOBAL transaction_isolation = 'READ-COMMITTED'; 在 MySQL 5.7 和部分 8.0 早期版本可用，但 8.0.16+ 起要求 SYSTEM_VARIABLES_ADMIN 权限，且某些部署（如云数据库 RDS）直接禁用该语句。
使用ydata-profiling（前身为pandas-profiling）生成全面的数据质量报告，包含相关性分析、缺失值模式和基数检测。导出交互式HTML仪表板和JSON摘要。
- 即使执行成功，也只影响后续新建连接，已有连接不受影响
- 若配置文件（
my.cnf）中存在transaction-isolation设置，它会覆盖SET GLOBAL的效果——这是新连接仍显示旧值的最常见原因 - 正确配置文件写法：
transaction-isolation = 'READ-COMMITTED'（必须用短横线，推荐加单引号） - 错误写法：
transaction_isolation = READ-COMMITTED（下划线，MySQL 启动时静默忽略）
验证是否真正生效，不能只看 SELECT @@transaction_isolation
该语句只返回变量值，不反映实际行为。例如 ORM（如 MyBatis、SQLAlchemy）可能在每次查询前重置隔离级别；连接池（如 HikariCP）可能在连接初始化时覆盖设置。
- 可靠验证方式：新开事务后立即查值 ——
BEGIN; SELECT @@transaction_isolation; COMMIT; - 行为级验证更关键：开两个会话，A 设为
READ COMMITTED并开启事务查某行；B 修改并提交同一行；A 再查是否看到新值 - 注意：若
AUTOCOMMIT = 1，单条SELECT本身就是一个隐式事务，快照生命周期极短，容易误判
连接池和 ORM 场景下，会话设置极易被覆盖
很多框架在获取连接后自动执行初始化 SQL，比如 Spring Boot 的 spring.datasource.hikari.connection-init-sql，若未显式包含隔离设置，或顺序不对（比如设在 START TRANSACTION 之后），就会失效。
- HikariCP / Druid 等连接池中，必须把
SET SESSION TRANSACTION ISOLATION LEVEL ...放在connectionInitSql里，且确保在任何业务 SQL 前执行 - MyBatis 默认不干预隔离级别，但若使用
@Transactional(isolation = ...)，Spring 会在事务开启前调用 JDBCsetTransactionIsolation()，这会覆盖你手动写的SET语句 - Django 默认每请求一个事务，且由 ORM 控制隔离级别，直接连 MySQL 客户端设的值基本无效
最易被忽略的一点：事务一旦启动，隔离级别就已锁定；后续再执行 SET 不会改变当前事务的行为，只影响下一个事务。这意味着调试时看到变量值变了，不代表正在跑的业务逻辑已按新级别执行。
