技术博客
TiFlash 是 TiDB 的列式存储引擎，通过异步复制 Region 副本实现 HTAP 场景下的实时分析加速。它不替代 TiKV，而是作为其补充：TiKV 负责高并发、低延迟的事务处理（行存），TiFlash 专注复杂 OLAP 查询（列存）。要真正发挥列存优势，关键不在“开了没”，而在“怎么配”和“怎么用”。
事务隔离级别直接影响数据库并发性能和数据一致性，选错级别会导致锁争用、死锁或不可重复读等问题。优化核心是：在满足业务一致性的前提下，尽可能使用更低的隔离级别，并配合索引、语句写法和事务粒度控制来减少锁范围与时长。
MySQL 的 OFFSET 不是跳过已扫描的行，而是真实地扫描并丢弃前 N 行。比如 SELECT * FROM orders ORDER BY id LIMIT 10000, 20，MySQL 会先按 id 排序，再逐行读取前 10020 行，只返回后 20 行——前 10000 行全白读了，还占 I/O 和 CPU。
当子查询返回大量数据，而外层表较小时，IN 容易因隐式去重和临时表膨胀变慢；相反，EXISTS 只需找到一条匹配就短路退出，对大结果集更友好。但反过来，如果子查询结果极少（比如只返回几行），且已建好索引，IN 可能更快——因为优化器能走 range 或 const 访问类型，而 EXISTS 仍要为每行外层数据执行一次相关子查询。
直接导出再导入函数，常遇到 Access denied; you need (at least one of) the SUPER privilege(s) 错误，根本原因是 DEFINER 用户在目标库不存在，或当前用户没权限模拟该定义者。
长事务会持有锁时间过长，阻塞其他事务，同时 undo log 持续增长，影响 purge 线程效率。常见于把整个批量导入、报表生成或跨服务操作包在一个事务里。
MySQL 触发器本身不开启新事务，而是**完全依附于触发它的 SQL 语句所处的事务**。也就是说，INSERT、UPDATE 或 DELETE 如果在显式事务中执行（比如包裹在 BEGIN / COMMIT 里），那么该语句激活的所有触发器逻辑都会被包含在这个事务里；如果语句是自动提交模式下的单条执行，那触发器也就在那个隐式事务中运行。
MySQL 的 user@host 是一个完整身份标识，’app_user’@’localhost’ 和 ‘app_user’@’%’ 完全是两个账号。很多人执行 CREATE USER ‘app_user’ IDENTIFIED BY ‘pwd’;，没写 @’host’，结果 MySQL 默认补成 @’%’ —— 这意味着该账号可从任意网络地址连接，是高危配置。
主从复制本质是单向数据同步，适用于读多写少、需要灾备或报表分离的场景。它不提供自动故障转移，主库宕机后必须人工介入切换，业务会中断。
SQL 聚合函数本身不支持直接嵌套（如 COUNT(SUM(…)) 会报错），但通过分组、子查询、窗口函数或 HAVING 等方式，可以灵活组合多个聚合结果，解决“每类中最大销量的平均值”“订单数超5的客户总消费额”等实际问题。