技术博客
跳过这步会导致后续无法登录、权限混乱，甚至 root@localhost 账户被锁定。安装完 MySQL 8.0（尤其是通过官方 mysql-installer 或 apt/brew 安装）后，不要直接尝试用 mysql -u root -p 登录——默认 root 密码不是空，也不是随机生成并打印在终端，而是由 mysqld –initialize 写入错误日志或临时文件。
MySQL 主从复制默认是基于 binlog 的逻辑复制，而触发器在从库执行时可能产生意料之外的副作用。最典型的问题是：主库执行一条 INSERT，触发器自动写入另一张表；从库重放这条语句时，如果也执行触发器，就可能导致重复插入、计数错乱或违反唯一约束。
这是 ERROR 1136 最常见的触发场景：插入语句中指定的字段个数与 VALUES 提供的值个数对不上。MySQL 会严格校验二者是否相等，哪怕只差一个，就直接报错。
多数数据库原生支持将查询结果导出为 XML，但语法和行为差异很大，不能写一次就到处跑。FOR XML 是 SQL Server 特有的语法，PostgreSQL 用 row_to_json() 或 xmlagg()，MySQL 则基本没内置支持——得靠应用层拼或用 SELECT … INTO OUTFILE 配合字符串函数硬凑。
直接回答：GRANT、REVOKE、CREATE USER 这类语句，MySQL 社区版默认**完全不记日志**——general_log 和 binlog 都靠不住。你翻遍 /var/log/mysql/ 也找不到一条权限操作记录，这不是配置错了，是设计如此。
长事务本身不直接消耗 CPU，但会持续持有锁、阻止 MVCC 清理、拖慢 purge 线程，最终让整个实例响应变慢甚至卡死。最典型的信号是 SHOW ENGINE INNODB STATUS 中看到大量 TRX_WAITING 或 purge lag 持续上涨。
不是数据库挂了，也不是 Liquibase 坏了，而是你在 changeSet 里写的 preConditions 没通过校验——比如表不存在、列类型不匹配、SQL 查询返回非空结果等。Liquibase 在执行前卡在这一步，直接中断，后续变更不会跑，也不会自动回滚已执行的上一个 changeSet。
因为 daisyUI 默认依赖 Tailwind 的 hover:、focus: 等变体（variants），而新版本 Tailwind 默认只启用部分变体；若未显式开启，btn-primary hover:bg-primary-focus 这类样式根本不会生成。
这不是回滚失败，而是回滚前等锁超时了。MySQL 在执行 ROLLBACK 前，会先尝试获取事务涉及行的排他锁（尤其在可重复读隔离级别下），如果这些行正被其他长事务持有锁且迟迟不释放，当前回滚操作就会卡住，直到 innodb_lock_wait_timeout（默认 50 秒）超时，报这个错。
用字符串存状态（比如 ‘pending’、’shipped’）看着直观，但查起来慢、改起来难、还容易拼错。MySQL 里最稳妥的是 TINYINT：0=待支付，1=已支付，2=已发货，3=已完成，-1=已取消。或者用 ENUM(‘pending’,’paid’,’shipped’,’done’,’canceled’)——它底层也转成整数，还能防非法值。