京公网安备11010502063487号本机真实对比排队期语法错误(EXECABORT整体丢弃)和运行时类型错误(WRONGTYPE，只影响那一条命令)，理解Redis事务为什么没有回滚机制。
本机真实用两个连接验证WATCH+MULTI+EXEC，被WATCH的key在EXEC前被修改会导致EXEC返回nil，整个事务取消。
本机真实用20线程并发压测非原子GET+SET(丢924次更新)对比原子Lua脚本(0次丢失)，验证Lua脚本原子性真实解决了丢失更新问题。
本机真实跑CPU密集Lua脚本，验证未超过lua-time-limit(5000ms)时其它客户端静默阻塞无错误，超过后才收到明确的BUSY错误。
本机真实用FUNCTION LOAD注册带名字的函数库并FCALL调用，对比裸EVAL脚本，验证Functions具备的名字管理和持久化能力。
本机真实验证EVAL一段从未LOAD过的新脚本会自动进入缓存，假SHA和SCRIPT FLUSH后EVALSHA都会报NOSCRIPT错误。
本机真实验证SCRIPT KILL能杀死一个纯计算的失控Lua脚本，但对已执行过写命令的脚本会被拒绝，报错UNKILLABLE。
本机真实验证PUBLISH和SUBSCRIBE都能被排进MULTI事务，但真正进入订阅模式后的连接只能执行极少数命令如PING。
本机真实在Lua脚本里用SORT对200万元素排序(2.33秒)，验证脚本阻塞主线程的根源是命令本身的时间复杂度，不是Lua代码量。
Kafka 事务能让一个 Producer 对多个 Topic/Partition 的写入要么全部提交、要么全部不可见。这次真实用一个事务型 Producer 往两个 Topic 各写一条消息，分别验证提交和中止之后 read_committed/read_uncommitted 两种隔离级别看到的内容有什么不同；中途还真实撞见一个容易漏掉的细节：中止事务时如果消息还没真正发到 Broker，客户端会直接把它悄悄丢弃，不会留下任何痕迹。
本机真实起一个 ClickHouse 26.9 单节点：200 次单行 INSERT 真实耗时 23.6 秒且产生大量 part，同样 200 行一次批量 INSERT 只要 0.14 秒；再用 ALTER TABLE UPDATE 验证一次更新真实是怎样的异步 mutation。
本机真实建一张 50 列的宽表，只查 1 列 vs 查全部 50 列，用 system.query_log 里真实的 read_bytes 数字看列存到底省在哪，以及为什么 length() 比 SELECT * 读得更少。