利益相关先说清楚：我们在做一个开源的数据库 IDE（MIT，自托管），里面有走 MySQL 协议的 Doris 驱动。下面每一条都是连真实实例一条条测出来的，不是照着文档抄的。第一条是我们自己的 bug，先说这个。
环境：Apache Doris 4.1.3-rc02-7126cf65d96，docker 单机实例。首次探测 2026-08-26，复测 2026-09-06。
0. 先认错：SHOW STATUS LIKE '...' 解析不过，是我们发错了
我们的概览面板和健康检查一直给 Doris 发 SHOW STATUS LIKE 'xxx'，Doris 回 mismatched input 'LIKE'，界面就在那个标签页上显示"这个数据库回答不了这个面板"，健康角标是 Slow。
问题是：不带 LIKE 的裸 SHOW STATUS 是能解析的，只是返回 0 行。改成裸的形式之后两个面板都正常渲染，角标变 Online。这个挂了十天，我们一直以为是 Doris 的事。
1. version() 返回 5.7.99，真实版本只在 会话变量 version_comment（读的时候前面要加两个 @） 里
version() 答的是 5.7.99，一个不存在的 MySQL 版本。真实构建号在 会话变量 version_comment（读的时候前面要加两个 @）：doris version doris-4.1.3-rc02-7126cf65d96。
和 StarRocks 的区别值得说一句：StarRocks 的 version() 答 5.1.0，但它还有 current_version() 可以兜底；Doris 没有这个函数，只能读 会话变量 version_comment（读的时候前面要加两个 @）。任何按 version() 判断能力的工具，在 Doris 上都会以为自己连的是 MySQL 5.7。
2. 外键既不可见，也不生效
ALTER TABLE ... ADD CONSTRAINT ... FOREIGN KEY 被接受，SHOW CONSTRAINTS 也列得出来。但是：
information_schema.KEY_COLUMN_USAGE里 0 行，所以画 ER 图的工具一条边都画不出来；- 我们插了一条引用
customer 424242（这个客户不存在）的订单，插入成功。
也就是说这个约束是优化器提示，不是完整性约束。文档里有，但工具侧很容易当成真约束处理。
另外 UNIQUE KEY 表在 information_schema.COLUMNS 里 COLUMN_KEY 读出来是 UNI 不是 PRI，对外部工具来说这张表等于"没有主键"。
3. information_schema.statistics 永远是空的
建了索引并确认存在，information_schema.statistics 依然 0 行，结果是一个索引都报不出来。StarRocks 上一样（BITMAP 索引，同样为空）。
4. EXPLAIN FORMAT='json' 解析不过
得发裸的 EXPLAIN。发裸的就正常：一个常量 SELECT 回了 18 行，我们画出 13 个节点的 Nereids 计划树，原文也能完整拿到。
5. 统计信息有大约一分钟的滞后，ANALYZE ... WITH SYNC 不管用
插入 2000 行之后立刻去读，所有接口都是 0 行 0 B。中间跑一次 ANALYZE TABLE ... WITH SYNC 没有任何变化。大约一分钟后，真实数字自己出来了。
这个形状和 TiDB 一样，是会自愈的延迟，不是缺陷。但对工具的后果是：刚导完数的表，在界面上看起来是空的。
6. 统计信息这块，Doris 比它的 fork 诚实
同一套探针，同样的两张表：
| Doris 4.1.3 | StarRocks 3.3.22 | |
|---|---|---|
| 3 行的表 | 3 行 / 2.65 KB | 0 / 0 |
| 2000 行的表 | 2000 行 / 9.95 KB | 0 / 0 |
getTableStats() 字节数 |
10187 B（SHOW DATA 说 9.948 KB） |
0 |
StarRocks 报硬零的原因我们也挖出来了：它对每张 BASE TABLE 的 INDEX_LENGTH 答 NULL，于是 DATA_LENGTH + INDEX_LENGTH 被 NULL 整个污染。Doris 这里答的是 0 而不是 NULL，所以同一条 SQL 在 Doris 上是对的。
这条也有我们的责任：我们当初直接写了两列相加，没有 COALESCE。2026-09-16 全部改成 DATA_LENGTH + COALESCE(INDEX_LENGTH, 0) 了。
7. 几个比我们预期好的地方
- 取消是真取消。 一条会跑 8 秒的
sleep查询，在 1513 ms 就死了，带着 Doris 自己的 cancel query by user。对比一下：Vitess 上根本取消不了。 - 活动会话和监控看板通过
information_schema.processlist是通的，存储统计也通。 - 权限错误的类别是对的，服务端原话完整传回来；
SELECT_PRIV的角色只能看到授权的那张表。 Analyze可用；Optimize和Check在语法里根本不存在，不是权限问题。SHOW STATUS不发布任何计数器，所以性能指标是空对象{}；没有Uptime、没有Threads_connected、也没有max_connections。我们的概览面板现在显示N/A, not published，而不是编一个 0 出来。
如果哪一条和各位在 4.x 上的实测对不上，很想听听，尤其是外键那条——我们只在 4.1.3-rc02 上试过。
项目：github.com/libredb/libredb-studio
