确认的方式，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能走在国内乃至世界的数据库前列！

支持同步ddl，根据ddl然后自己处理一下再处理变更

太有必要了，我要严重呼吁增加物化视图 场景描述： 目前做实时数据开发，基于tidb+flink 如果有物化视图，基本不需要搭建ticdc ,kafka，flink ， 还有flink ck 存储的hadoop 。 目前基表很多，但是一般join 需要2-6张表这样子 ，这些表全部是持续写入。 更新延迟秒级别。 单个物化数据量不足TB级别，到几兆（维度表）到几百G(多事实聚合) 都有。 表均存在更新，删除比较少，我们这里目前将删除进行打flag 软删除。 痛点描述： 系统目前通过基于ticdc+kafka+flink+tidb 实时 开发处理，由于flink sq…