技术博客
GTID（Global Transaction Identifier）是 MySQL 5.6+ 引入的全局事务唯一标识，格式为 source_id:transaction_id（如 e1e2f3a4-5678-90ab-cdef-1234567890ab:1）。它替代了传统基于 binlog filename + position 的复制定位方式，核心优势在于：事务在集群中可被唯一识别、无需人工计算位点、支持自动跳过已执行事务、主从切换后仍能准确定位同步起点。
MySQL 在执行一条 SELECT、INSERT 等语句时，会先经过「解析器（Parser）」进行语法分析，这是整个查询生命周期的第一步。它不检查表是否存在、字段有没有权限，只确认 SQL 字符串是否符合 MySQL 自己的语法规则。
直接在浮动元素后面加 clear: both 看似合理，但实际常失效——因为 clear 只对「自身所在的块级盒」起作用，且要求该元素必须是浮动元素的「后续兄弟元素」。如果父容器内部只有浮动子项，而你没放任何兄弟元素（比如空
），那 clear 就无处安放。
因为LEFT JOIN必须保留左表全部记录，即使右表没有匹配项也要补NULL，导致MySQL无法像INNER JOIN那样提前剪枝。执行计划里常看到Using where; Using join buffer，说明它在用缓存做嵌套循环，数据量一大就卡。
Ant Design 本身不是“快速搭建 UI 组件”的工具，而是提供了一套已实现、可配置、需集成的成熟组件库；你无法用它“生成”新组件，但能极快地组合出符合企业级规范的界面。
MySQL 中 INDEX 的实际长度不等于你定义的列长度（比如 VARCHAR(255)），而是取决于该列的字符集、排序规则和存储引擎对索引前缀的限制。InnoDB 对单个索引列的前缀长度上限是 767 字节（utf8mb3）或 3072 字节（utf8mb4 + innodb_large_prefix=ON，且行格式为 DYNAMIC 或 COMPRESSED）。超长会直接报错：ERROR 1071 (42000): Specified key was too long。
表锁是“一把锁关整扇门”，行锁是“给门上某把锁只锁住一个抽屉”。这不是粒度粗细的修辞，而是直接影响你线上事务是否排队、接口是否超时的真实机制。
安装完 MySQL 后，默认通常 general_log 是关闭的，它记录所有执行的 SQL 语句，适合调试但不建议长期开启。检查是否启用：SELECT @@general_log;返回 0 表示关闭；1 表示开启。日志文件路径由 general_log_file 变量决定：SELECT @@general_log_file;常见默认值是 /var/lib/mysql/hostname.log（Linux）或 C:ProgramDataMySQLMySQL Server X.XDatahostname.log（Windows）。若需开启，执行：SET GLOBAL general_log = 1;注意：该设置重启后失效，要永久生效需写入配置文件。
MySQL 的执行计划（EXPLAIN 输出结果）不是在客户端拼接 SQL 时生成，也不是在存储引擎读数据时才决定，而是在 Server 层的查询优化器（Query Optimizer）完成逻辑解析和语义检查之后、实际执行之前生成的。具体来说，它发生在：parser → resolver → optimizer → executor 这一链条中的 optimizer 阶段。
当IN查询参数超过2100个（SQL Server限制），Dapper原生语法 WHERE Id IN @Ids 会直接报错——这不是Dapper的缺陷，而是SQL Server底层协议（TDS）对单条命令参数数量的硬性约束。绕过它需要改变数据传递方式，而非拼接字符串。