技术博客
Symfony 项目里，依赖分两类：运行时必需的（比如 doctrine/orm），和只在开发/测试时需要的（比如 phpunit/phpunit 或 symfony/debug-bundle）。
错放会直接导致生产环境出问题：把调试工具塞进 require，上线后可能暴露敏感信息；反过来，把 symfony/console 放进 require-dev，bin/console 就直接报错。
本文介绍如何在 polars 中对两个嵌套列表列（`a` 为整数列表，`b` 为字典列表）执行类似 sql left join 的操作：先展开两列，再按 `a[i] == b[j].id` 关联，并为每个 `a` 元素保留对应的 `b.x` 值（未匹配则为 `null“。
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/ 也找不到一条权限操作记录，这不是配置错了，是设计如此。
清理过期 MySQL 备份是释放磁盘空间、保障备份系统稳定运行的关键操作。重点不是“删得越多越好”，而是“删得准、留得稳”——保留满足恢复要求的最小必要备份集，同时避免误删或遗漏。
长事务本身不直接消耗 CPU，但会持续持有锁、阻止 MVCC 清理、拖慢 purge 线程，最终让整个实例响应变慢甚至卡死。最典型的信号是 SHOW ENGINE INNODB STATUS 中看到大量 TRX_WAITING 或 purge lag 持续上涨。
不是数据库挂了，也不是 Liquibase 坏了，而是你在 changeSet 里写的 preConditions 没通过校验——比如表不存在、列类型不匹配、SQL 查询返回非空结果等。Liquibase 在执行前卡在这一步，直接中断，后续变更不会跑，也不会自动回滚已执行的上一个 changeSet。
MySQL 客户端（mysql 命令行工具）默认会把执行过的 SQL 写入用户家目录下的 ~/.mysql_history 文件，但这个行为受多个条件限制：
• 只有在未设置环境变量 MYSQL_HISTFILE 为 /dev/null 或空字符串时才生效
• 若用户以 mysql -e "SELECT 1" 方式执行命令，语句不会写入历史文件
• ~/.mysql_history 是纯文本、无时间戳、无用户标识、无连接上下文，无法区分是哪个账号、连的哪台实例、何时执行的
• 文件权限若配置不当（如被其他用户可读），反而构成安全风险