在 TiDB 中，统计信息包括：
直方图（Histogram） 
用于估算列值分布
支持：
等值查询（=）
范围查询（>、<、BETWEEN）
和 MySQL 类似，但实现更偏向分布式优化
CMSketch（Count-Min Sketch）
用于估算 高频值（TopN）
解决数据倾斜问题
TopN
精确记录最常见的值
比 MySQL 更先进
扩展统计（Extended Stats）
多列相关性（correlation）
用于优化 join / 多列过滤
总结一句
TiDB 的统计信息 不仅有直方图，而且比 MySQL 5.7 更强
直方图（Histogram）
用于估算列值分布
支持：
等值查询（=）
范围查询（>、<、BETWEEN）
和 MySQL 类似，但实现更偏向分布式优化
CMSketch（Count-Min Sketch）
用于估算 高频值（TopN）
解决数据倾斜问题
TopN
精确记录最常见的值
比 MySQL 更先进
扩展统计（Extended Stats）
多列相关性（correlation）
用于优化 join / 多列过滤
总结一句
TiDB 的统计信息 不仅有直方图，而且比 MySQL 5.7 更强1 个月前
TiDB 支持的 Join 算法
Index Nested Loop Join（INLJ）
类似 MySQL 5.7
适合：小表驱动大表 + 有索引
最常见
Hash Join （重点）
TiDB 默认最常用
构建 hash 表（build side）
探测匹配（probe side）
适合：
大表 join
无索引场景
Hash Join: build hash on smaller table, then probe with larger tableHash Join: build hash on smaller table, then probe w…1 个月前
不需要。
在 TiDB 里：
建表时不是必须指定分区，默认就是非分区表。
什么时候“不需要分区”（大多数情况）
如果你的表：
数据量不大（比如 < 几千万 / 几 GB）
访问模式简单（主键/索引查询）
没有明显冷热数据
直接建普通表即可
CREATE TABLE t (
id BIGINT PRIMARY KEY,
name VARCHAR(100)
);
TiDB 会自动做：
Region 切分
数据分布
已经具备“自动分片能力”
很多人误解的点
TiDB 本身已经是分布式的 ≠ 必须手动分区
普通表 → 自动按 Region 分裂（底层）
…
建表时不是必须指定分区，默认就是非分区表。
什么时候“不需要分区”（大多数情况）
如果你的表：
数据量不大（比如 < 几千万 / 几 GB）
访问模式简单（主键/索引查询）
没有明显冷热数据
直接建普通表即可
CREATE TABLE t (
id BIGINT PRIMARY KEY,
name VARCHAR(100)
);
TiDB 会自动做：
Region 切分
数据分布
已经具备“自动分片能力”
很多人误解的点
TiDB 本身已经是分布式的 ≠ 必须手动分区
普通表 → 自动按 Region 分裂（底层）
…1 个月前
在没有 TiProxy 的情况下，用 SLB 直连多个 TiDB Server：
会导致连接闪断的情况
TiDB Server 重启 / 升级 / 下线
SLB 健康检查剔除节点
一定会断连接（客户端需要重连）
会导致连接闪断的情况
TiDB Server 重启 / 升级 / 下线
SLB 健康检查剔除节点
一定会断连接（客户端需要重连）1 个月前
方案1（推荐）：提前建好 topic
./kafka-topics.sh --create
–bootstrap-server xxx:9092
–topic topic_ticdc_saleslink_uc_employee_emp_employee
–partitions 3
–replication-factor 3
优点：
完全可控
最稳定
生产推荐
方案2：关闭 Kafka 自动创建 topic
在 Kafka 配置中：
auto.create.topics.enable=false
然后：
TiCDC 写入失败（因为 topic 不存在）
强…1 个月前
partition-num=3 只对“默认 topic”生效
你配置的 topic_ticdc_{schema}_{table} 是 动态 topic ，不会使用这个参数
动态 topic 的分区数 = Kafka broker 默认分区1 个月前
执行流程
第一步
TiDB 生成执行计划
TopN(offset 50 count 200)
↓
TableReader
↓
TopN pushdown
↓
TableFullScan
逻辑是：
Top 250
不是 200。
因为：
offset + count
第二步
TopN 下推到 TiKV
每个 Region 都会执行：
Top 250
即：
region1
返回
0-100
最多100行
region2
返回
101-200
最多100行
region3
返回
201-300
最多100行
但：
只需要
250
第三…
2 个月前
为什么 order by limit 慢
因为：
每个 region 都要返回 Top250
而不是：
只要200
所以：
region数越多
分页越慢
特别是：
limit 100000,10
会变成：
Top100010
非常重。
2 个月前
如何确认是哪种原因
需要看系统表。
查看慢 SQL
select *
from information_schema.slow_query
where query like ‘%point_get%’
order by time desc
limit 10;
关注：
Write Conflict
Lock wait
Backoff
TxnRetry
查看事务重试
select *
from information_schema.cluster_tidb_trx;
看：
waiting_start_time
state
查看锁
select *
f…
查看慢 SQL
select *
from information_schema.slow_query
where query like ‘%point_get%’
order by time desc
limit 10;
关注：
Write Conflict
Lock wait
Backoff
TxnRetry
查看事务重试
select *
from information_schema.cluster_tidb_trx;
看：
waiting_start_time
state
查看锁
select *
f…2 个月前
写冲突（最常见）
典型场景：
update user set age=20 where id=1;
同时另一个事务：
select * from user where id=1;
或
update user set age=21 where id=1;
TiDB 会发生：
Write Conflict
或
Lock Conflict
流程：
事务A锁住key
↓
事务B point_get
↓
等待锁
↓
超时
↓
事务重试
就会看到：
point_get 3秒
txn retry
三、为什么 point_get 会变成 3 秒
因为 TiDB …
2 个月前
核心原因
TiDB 的 SLOW_QUERY / CLUSTER_SLOW_QUERY 是内存表 / 临时汇总表
它不是普通 InnoDB 表，不会自动在事务中刷新。
pymysql 默认开启自动提交 = False，会进入一个长事务
你在 Python 里第一次连接后，就进入了一个事务快照。
之后慢查询新产生的数据，在这个事务里看不见。
而你在命令行：
• 要么每条语句自动提交
• 要么每次重连新会话
所以能查到最新数据。
2 个月前
这种情况在 TiDB 里非常典型，不是时区问题，而是 TiDB 慢查询表的会话可见性 / 刷新机制 + pymysql 默认事务隔离级别
2 个月前
TiKV 未释放空间的原因
1）SST import 临时文件
路径
/data1/tidb-data/tikv-20160/import
里面会有：
.temp
.sst
这些是 restore 过程产生的。
如果 restore 中断：
不会自动清理。
2）删除库只是逻辑删除
你执行了：
drop database
但：
数据不会立即删除
因为 TiDB 是：
MVCC + GC 回收
删除后：
数据进入：
GC 等待阶段
只有 GC 后才真正释放。
3）GC 停在凌晨
你说：
gc时间停在凌晨
说明：
GC 没推进
检查：
mys…
2 个月前
您提到：
• 部分 TiKV 磁盘空间爆满
• GC 时间停在凌晨
这是典型的 GC 积压导致空间未释放 问题。当 BR 恢复失败中断时，会产生大量临时数据和版本堆积。
解决方案
紧急释放空间（已爆满节点）
– 检查当前 GC 状态
SELECT * FROM mysql.tidb WHERE VARIABLE_NAME LIKE ‘%gc%’;
– 手动触发 GC（谨慎操作）
UPDATE mysql.tidb SET VARIABLE_VALUE = DATE_FORMAT(DATE_SUB(NOW(), INTERVAL 1 HOUR), ‘%Y%m%d-%H:%M:%…
2 个月前
没有更多内容了