MySQL慢查询日志本身不支持着色，需在查看阶段用awk/grep动态高亮；CLI耗时标红需捕获stderr；SQL批量执行推荐Python精确计时着色；所有方案均依赖终端支持ANSI颜色。
MySQL 慢查询日志里怎么让耗时数字自动标红
直接改日志本身做不到——mysqld 输出的慢查询日志是纯文本，不带颜色。真要“爆红”，得在查看阶段加处理，不是在生成阶段。
最常用也最轻量的办法：用 grep 或 awk 配合终端着色，在读取日志时动态高亮超时行。比如把执行时间 ≥ 2 秒的整行标红：
awk '$NF+0 >= 2 {print "\033[31m" $0 "\033[0m"; next} 1' /var/log/mysql/slow.log注意：$NF 是最后一列（MySQL 慢查日志末尾是 Query_time: 后的数值），+0 强制转为数字避免字符串比较出错；\033[31m 是红色 ANSI 码。
- 别直接用
grep -E "Query_time: [2-9]\.|[1-9][0-9]"—— 它只能匹配文本，无法区分 1.95s 和 2.01s，精度不够 - 如果日志用了
log_output = TABLE存进mysql.slow_log表，就得换 SQL 方式查，没法用终端着色 - 某些旧版终端（如 Windows CMD）不支持 ANSI 颜色，会显示乱码，优先用
WSL、iterm2或mintty
MySQL 客户端执行 SQL 时实时标红耗时
MySQL CLI 本身不提供执行耗时着色功能，但可以通过 shell 包装实现：把 mysql 命令套一层脚本，捕获输出里的 Query OK 或 Rows matched 行及前面的耗时提示。
关键点在于 MySQL CLI 默认会在每条语句后打印类似 1 row in set (0.32 sec) 的信息，它其实走的是 stderr，可单独截获：
mysql -u root -p -e "SELECT SLEEP(1);" 2> >(awk '/sec)/ && $(NF-1)+0 > 0.5 {print "\033[31m" $0 "\033[0m"; next} 1' >&2) 这个命令对 stderr 做了实时过滤，只要括号里秒数 > 0.5 就标红。
-
2> >(...)是 bash 进程替换语法，不能在 dash/sh 下用，确保用bash启动脚本 - 别试图修改
my.cnf里的pager配置来着色——pager只作用于查询结果，不包含耗时统计行 - 如果开了
profiling=ON，耗时分散在多行，这种简单匹配会失效，得用更重的解析逻辑
SQL 文件批量执行时按耗时分色输出（Python 脚本方案）
当需要跑一堆 .sql 文件并监控每条语句耗时，CLI + shell 组合太脆弱，推荐用 Python 控制执行流，自己测时、判断、着色。
核心是用 mysql-connector-python 或 pymysql 执行单条语句，并用 time.time() 包裹。超过阈值就用 \033[31m 打印语句和耗时：
import time
import mysql.connector
conn = mysql.connector.connect(user='root', password='', database='test')
cursor = conn.cursor()
for sql in open('batch.sql').read().split(';'):
if not sql.strip(): continue
t0 = time.time()
try:
cursor.execute(sql)
dt = time.time() - t0
color = '\033[31m' if dt > 1.0 else ''
print(f"{color}→ {sql[:50]}... ({dt:.3f}s)\033[0m")
except Exception as e:
print(f"\033[33m! {sql[:30]}... ERROR: {e}\033[0m")这样每条语句独立计时，比看整体执行时间靠谱得多。
- 别用
subprocess.run(['mysql', '-e', sql])—— 启动新进程开销大，且无法精确到单条语句粒度 - 注意
autocommit=False时，COMMIT本身也会被计时，需单独判断语句类型 - 如果 SQL 含注释或换行，
split(';')会切错，得用真正 SQL 解析器（如sqlparse）做安全切分
为什么不用 Prometheus + Grafana 做“红灯告警”
因为这不是日志着色问题，而是监控告警场景。如果你已经上了 mysqld_exporter，那 mysql_global_status_slow_queries 和 mysql_info_schema_processlist_time 这类指标能反映慢查询趋势，但它们不记录单条 SQL 内容，更不会“爆红显示原始 SQL”。
想在 Grafana 里让某条 SQL 爆红，得先让它进日志、再进 Loki/ELK、最后写 LogQL 查询提取 Query_time 并配告警颜色——链路长、延迟高、还依赖日志格式稳定。
- 别指望
performance_schema.events_statements_history_long直接导出带颜色的 HTML 表格——它没渲染能力，只是张内存表 - 开发环境用着色脚本够用；生产排查才值得上 ELK+Grafana 这套，否则就是杀鸡用核弹
- 最常被忽略的一点：所有着色方案都依赖终端解释 ANSI 序列。发邮件、存文件、贴进钉钉/企微时，颜色全消失，只剩乱码
