避免热点:
1、应用雪花算法，数据库层面需去掉AUTO_INCREMENT
2、应用层面不做改动，数据库层面采用AUTO_RANDOM
3、应用层面不做改动，数据库层面使用SHARD_ROW_ID_BITS = 4 PRE_SPLIT_REGIONS = 2;
应用采用了雪花算法，数据库继续使用AUTO_INCREMENT是冲突的是吗？
统一多表更新时的加锁顺序避免死锁。
雪花算法在 TiDB 仍然会有热点存在，最好使用 AUTO_RANDOM
AUTO_INCREMENT 可以理解为自动递增的信息，和传统数据的方式类似。这个和雪花的模式差异较大，不可混用。
否则，同一个表同一个主键又是 1 - 1000，也有可能是 999xxxx1011 , 这种跳跃可以接受么？
1 个赞
二者会产生主键冲突，绝对不能混用。
乐观锁写写冲突导致重试，高冲突场景建议加悲观锁。
雪花 ID + AUTO_INCREMENT 属于两套主键生成机制叠加，会造成主键数据两极分化，业务长期运行必然出隐患，二者不能共存。
只能用其中一种
AUTO_INCREMENT未必有热点，每个tidb-servier默认都是30000个自增 ，用完再拿新的
可以接受的话，就可以保留雪花ID+AUTO_INCREMENT这种组合吗？
session.go:819] [sql] [label=internal] [error=“[kv:9007]Write conflict, txnStartTS=467330591944605706, conflictStartTS=467330591944605707, conflictCommitTS=0, key={tableID=54, tableName=mysql.column_stats_usage, handle={24460, 3}}, originalKey=7480000000000000365f72038000000000005f8c038000000000000003, primary=byte(nil), originalPrimaryKey=, reason=Optimistic [try again later]”] [txn=“Txn{state=invalid}”]
日志好多]Write conflict, 是因为雪花ID +AUTO_INCREMENT 一起使用导致的吗？
是这样的，但是业务量大的话，这个AUTO_INCREMENT确实存在热点
不太好，会导致region对数据的拆分会出现问题了
又学到了，雪花算法 
不会冲突呀呀，你传了值，数据库就用你传的雪花 ID；你不传，数据库才用自增值。两者不会同时生效，因此不存在功能冲突
如果已经落地雪花算法，建议移除AUTO_INCREMENT，明确主键由应用生成，避免后续误操作
误操作是指什么呢？会有什么隐患在吗？
既然业务已经接入雪花算法，最优做法是直接去掉AUTO_INCREMENT，省去 PD 自增 ID 分配的额外交互，彻底消除写入热点；
比如某段代码、某个批量脚本漏写了主键值，数据库会自动生成自增 ID 插入，最终表内出现 “一部分雪花 ID、一部分自增 ID” 的混乱情况
是的,去掉AUTO_INCREMENT
应用已用雪花 ID 时，表不应再依赖 AUTO_INCREMENT 自增主键，否则两套发号可能冲突或浪费。建议：主键改为 BIGINT，去掉 AUTO_INCREMENT，由应用写入雪花 ID；若仍想用 DB 侧打散热点，可用 AUTO_RANDOM 替代。三者选一并统一，不要应用发号 + 列上 AUTO_INCREMENT 并存。
1 个赞