咖啡杯旁的绿植是不是也可以被抽

1、时来运转 2、福蛇盈门 3、十拿九稳 4、心想事成 5、开门见山 6、画蛇添足 7、打草惊蛇 8、瞠目结舌 9、依依不舍 10、龙蟠虎踞 11、巧舌如簧 12、唇枪舌剑 13、 引蛇出洞

确认的方式，index的话表现查询count走索引，现实数据量不对，但是查漏掉数据的时候where ID=**可以查询到，这个时候走tikv get by rowID，没有走索引

确认下这个region是indexregion的话，那就还好，可以通过tikvscan。api获取全量数据，如果不行那就不能用scan了

另外看到你有监控可以配合看下topSQL ,关闭 资源使用高的SQL

可以这样子不，show process list; 查询到执行的sql ,然后 kill tidb xxx；先将查询停掉

kill 不行，无限重启

增加 --force 可以卸载成功，更改配置文件重装就好了

第二个我更改一下配置文件，现在不知来的及不

这个9100端口一直开着，而且关闭不掉

现在是启动启动不了，销毁销毁不了

[image] 我突然发现你在同一个机器上面挂在同一个地址，同一个IP，同一个端口号 ,这个能起来就神奇了

赶快试试向量特性，先吃肉

你查一下20160 端口是否被占用了，看报错 time out waiting for port 20160 ，使用netstat -nlp | grep 20160

不水才能不拉垮

【最符合预期的功能有哪些】索引优化 【哪些功能还需要继续改进】分区表分区字段必须为主键，有的时候分区字段不是主键，如果可以创建非主键分区表，对查询效率来说很有帮助 【哪些功能对你帮助不大】tiflash ，首先都是个人主观观点，如果你觉得我说的不对，完全是我的问题。这个产品很尴尬，处于一个鸡肋产品，写入受tidb 写入控制，也就是受tidb 写入多快，他就能多快，tidb 关系型数据库，写入本身不是强项。另外不像doris,starRocks 有优化聚合模型，还有查询优化，所以很难成功。

SQL查询不到， 当你的表是单个主键的时候 主键是整数数字类型，的时候row_id 是主键的数字，当不是的时候是自动生成数字，这个数字不和主键有直接关系，但是可以通过代码解析出来。其逻辑应该是生成一个row_id ，key(table_id ，row_id)——》value(主键) ，可以通过tikv client 查询出来。 当你的表不是单个主键， rowid 随机生成，保存再tikv 中，逻辑大概可以表示为（table_id,row_id）->(value1(主键1)。。。。valueN（主键N）)

从tidb5走到tidb8，我们是使用者，见证者，肉眼可见tidb越来越好。看到未来规划规划部分，相信tidb能走在国内乃至世界的数据库前列！