应实时抓取活跃会话：用SELECT * FROM information_schema.PROCESSLIST WHERE COMMAND != 'Sleep' AND TIME > 2定位超2秒的危险操作，重点检查INFO字段中无WHERE的UPDATE/DELETE及STATE为Copying to tmp table等低效状态。
怎么快速定位正在执行的危险 SQL
危险操作（如没 WHERE 的 UPDATE、DELETE，全表扫描的 SELECT）往往在运行时才暴露风险。靠慢查询日志漏检率高——它只记录执行完且超时的语句，而杀伤力最大的可能是几秒内就改掉百万行的“快但危险”操作。
真正管用的是实时抓活会话：SHOW PROCESSLIST 或更可靠的 information_schema.PROCESSLIST。它能立刻看到谁在跑什么、卡在哪、用了多久。
-
SELECT * FROM information_schema.PROCESSLIST WHERE COMMAND != 'Sleep' AND TIME > 2;—— 过滤掉空闲连接，重点关注运行超 2 秒的活跃操作 - 重点盯
INFO字段：如果看到UPDATE users SET status=0没带WHERE，或DELETE FROM orders后面光秃秃的，马上KILL对应的ID - 注意
STATE值：如果是Copying to tmp table或Sorting result，大概率是没走索引的大查询，不是慢，是“蠢慢”
慢查询日志开不开、怎么设阈值才不误伤
开慢查日志本身不重，但设错 long_query_time 就容易废掉：设太高（比如 10 秒），漏掉大量实际拖垮 DB 的中等查询；设太低（比如 0.1 秒），日志爆炸，磁盘写满比性能问题来得还快。
真实建议是分层设：线上核心库用 long_query_time = 1，再配合 log_queries_not_using_indexes = ON（但仅限低峰期开启，否则日志量翻倍）。
-
SET GLOBAL long_query_time = 1;—— 动态生效，不用重启，但注意该变量对已连接会话无效 - 必须确认
slow_query_log = ON且slow_query_log_file路径有写权限，常见坑是 MySQL 用户没权限往/var/log/mysql/写 - 日志里
Rows_examined: 524800比Query_time: 0.892345更值得警惕——说明扫描了 52 万行才返回 10 行，索引失效了
错误日志里根本看不到 SQL，只有一堆“Access denied”或“Deadlock found”
MySQL 错误日志（error.log）默认不记录具体 SQL，只记权限、连接、崩溃类事件。想审计“谁在什么时候执行了什么危险语句”，不能只盯它。
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
真正要补的是通用查询日志（general_log）或使用代理层（如 ProxySQL、MaxScale）做 SQL 拦截。但前者性能代价大，后者需要额外部署。
-
SET GLOBAL general_log = ON;+SET GLOBAL log_output = 'TABLE';—— 把日志写进mysql.general_log表，比文件方式稍可控，查起来也方便 - 别长期开着
general_log：每条连接建立、每条语句执行都记，QPS 1000 的库一天轻松写几个 GB - 如果只能用错误日志，重点看带
Aborted connection和Got an error reading communication packets的条目——它们常伴随异常中断的长事务，背后可能就是没提交的危险操作
audit_log 插件装了但没记录 DROP TABLE
audit_log 是 MySQL 官方企业插件，但默认策略极保守：只记录登录、退出、权限变更，不记录 DML/DQL。连 DROP TABLE 都不记，除非你手动调大 audit_log_policy 级别。
它和 Percona 的 audit_plugin 不是一回事，别混淆。原生 audit_log 在社区版里压根不带，只有企业版提供，且配置项少、扩展性差。
- 检查是否真加载成功：
SELECT PLUGIN_NAME, PLUGIN_STATUS FROM INFORMATION_SCHEMA.PLUGINS WHERE PLUGIN_NAME = 'audit_log';—— 返回空说明没装或加载失败 - 即使装了，
audit_log_policy = 'ALL'才可能捕获 DDL，但依然不保证记录 DML；且它不解析 SQL 内容，只记动作类型（如drop_table）和用户 - 真要细粒度审计，不如直接上
pt-query-digest解析慢查日志 +PROCESSLIST快照组合分析，更轻量、更可控
最麻烦的从来不是“怎么记”，而是“记下来之后怎么从海量日志里一眼揪出那条正在删库的语句”。过滤逻辑、时间窗口、用户白名单，这些才是实际落地时卡住人的地方。
