-
MySQL 8.0前子查询中ORDER BY + LIMIT报错是因语法不支持，错误码1235；解决方法是外移排序逻辑，改用派生表或窗口函数，并确保WHERE条件置于窗口外、日期范围用开区间避免截断。子查询里用 ORDER BY + LIMIT 1 为什么总报错？在MySQL 8.0之前，要是在子查
-
ORDER BY RAND()在MySQL中极慢，因其必须全表扫描、为每行计算RAND()并全量排序，即使LIMIT 1也无法避免，100万行耗时可达30秒，且索引完全失效；替代方案为主键范围随机采样等避开排序的方法。因为 RAND() 在大多数数据库里触发全表扫描 + 全行随机数计算 + 全量排序
-
动态字段名拼接必须白名单校验，且参数绑定须用计算属性语法；JSONB模糊查询需确保字段为JSONB类型并建GIN索引；复杂场景应改用原生SQL+占位符参数化。动态字段名拼接必须白名单校验TypeORM的andWhere对于字段名（比如JSONB路径row_data->>'Location'里的Loc
-
STRING_AGG必须指定非NULL分隔符且排序需在函数内显式声明；它自动跳过NULL但保留空字符串，应优先于array_agg+array_to_string，处理数组字段需先unnest。STRING_AGG 语法必须带分隔符，不能省略或传 NULL 在PostgreSQL 15里，STRIN
-
A VG()忽略NULL是标准行为，但会导致业务语义错位、报表失真、基数不可知、全NULL组返回NULL及COALESCE与A VG嵌套语义混淆等问题。A VG() 忽略 NULL 不是 bug，是标准行为；但业务上常把它当“没影响”，结果算出的平均值根本不是你想要的那个“平均”。 A VG() 的
-
一对一关联表中间出现重复行，这表明右表的外键实际上并非唯一。我们应当先通过SELECT foreign_key, COUNT() FROM child_table WHERE foreign_key IS NOT NULL GROUP BY foreign_key HA VING COUNT() >
-
CTE可不是万能的语法糖，其是否适用取决于复用性、逻辑复杂度以及数据库的物化策略。只有在同一子查询被引用不少于2次、包含聚合/窗口/多表JOIN、嵌套超过2层且语义清晰、需要递归处理的情况下，才建议使用CTE。在命名CTE时，必须显式声明列，以避免SELECT*和同名列冲突。MySQL 8.0+默认
-
MySQL 的 performance_schema 会把近期语句按事件记录下来，DIGEST 还能把字面量不同的同类 SQL 归并观察。本文用 events_statements_history_long 说明如何抓取异常语句、区分总耗时与单次耗时，并处理历史表为空、采样范围有限等问题。
-
Redis HRANDFIELD 适合从 Hash 中抽取随机字段。本文用 redis-cli 核对单字段、COUNT、WITHVALUES、负数 COUNT、空键和重复结果，避免把随机读取误当成去重抽样。
-
用最小 SQL 验证 MySQL READ ONLY 事务的真实边界：哪些普通表写入会失败，为什么临时表仍可修改，以及连接池复用时如何确认只读状态没有泄漏。
-
Redis SORT_RO 是 SORT 的只读变体，适合在只读副本上完成列表、集合或有序集合排序。本文用商品候选列表拆开 LIMIT、GET、ALPHA 的结果边界，解释为什么 SORT 会被导向主节点，以及如何验证查询结果和复杂度风险。
-
MySQL 8.4 支持多个复制通道从不同源端汇聚到一个副本。本文从 channel 级状态、并行 worker、过滤边界和冲突风险出发，整理多源复制的配置与排查方法。
-
Redis 的服务端缓存很快，但高频读请求仍可能把网络和序列化成本推到应用侧。本文用 Redis Tracking 演示本地缓存如何接收失效通知，比较默认模式与 OPTIN，说明 RESP3、重连、写后读取和广播模式的边界，给出一套可验证的落地检查清单。
-
把订单金额、状态和时间关系交给应用层校验，批处理或旁路写入仍可能留下脏数据。本文用 MySQL 8.4 CHECK 约束建立可落地的边界，演示新增约束前的存量检查、失败写入的错误定位、约束命名和回滚步骤，避免一次结构变更卡住发布。
-
Redis Hash 变大后，真正难排查的常是某几个字段值异常膨胀。本文用 HSCAN NOVALUES 先低成本找字段，再按需回读长度并设置告警阈值，避免把整份 Hash 搬到应用内存。
