业务场景：为了实现用户配置动态字段数据存储，在tidb上创建了单表2000多列来存储用户数据，由于Tidb单表索引列数最大为512，单表最大列数为4096列，所以只能单表开启了Tiflash,因为用户可以配置任何一列作为查询条件，随着数据的增涨，出现了查询慢sql（慢查询依据为默认设置）
具体操作步骤：
1.创建单表2000多列（字符串、数字、日期、Array各500列、还有几个有索引的列）上线运行时，数据量比较小也没有报慢查询
2.观察一定时间后打算给每种类型（字符串、数字、日期、Array）各增加500列，即每种类型为1000列，出现了delete、update慢查询，还有一些select的慢查询 有时也出现tidb服务器过载error
3.删除掉表重新建表并开启Tiflash，（字符串、数字、日期、Array）各类型还是还原到每种类型500列,随着用户数据量的增涨，delete、update、select就大量出现慢查询了，并且有时也会报Tidb服务器load过载error
对于我们这种大宽表场景，在服务器方面是否有优化方案呢？
动态字段数据存储 为啥不考虑用 JSON ？
可以考虑下拆分表
业务沟通垂直分表，数据分区 ，1楼大佬说的动态字段存json，json的话是不是考虑下符不符合场景了
大宽表我只在数仓见过
好奇是什么业务数据
再创建一个从中心，负责select ， 主中心负责update insert ，delete 操作去掉建议变成删除标识，不要直接删除数据。主从通过ticdc ，ticdc tidb -tidb 还是很稳定的。最好还是拆分表。
json效率也很差，这种还是横向拆表吧。。。。
还是拆分表，比优化来得快
可以考虑按列拆分表，然后使用表关联
这种表设计，数据库能做的只是在传输时压缩下数据大小，效果如何只能试试看，这么宽的表估计资源额外开销都很大
https://docs.pingcap.com/zh/tidb/stable/tidb-configuration-file#grpc-compression-type
https://docs.pingcap.com/zh/tidb/stable/tikv-configuration-file#grpc-compression-type
ap 场景，确认select 有效字段，尽可能还是避免这种，适当拆分一下，这也不好维护啊
拆分表好点
https://docs.pingcap.com/zh/tidb/stable/titan-overview
你可能需要尝试一下titan。我个人是没有使用过。不过看描述就是因为应对vale比较大的场景的。
Titan 是基于 RocksDB 的高性能单机 key-value 存储引擎插件。
当 value 较大（1 KB 以上或 512 B 以上）的时候，Titan 在写、更新和点读等场景下性能都优于 RocksDB。但与此同时，Titan 会占用更多硬盘空间和部分舍弃范围查询。随着 SSD 价格的降低，Titan 的优势会更加突出，让用户更容易做出选择。
这种在大数据都算比较大的宽表了，还是拆表靠谱些
默认 TiDB 单行有 6 M 的限制，索引也有长度限制，为了性能一般不建议调整，你可以尝试测下 Titan 。
拆表批量跑会好一点吧
很好奇当初是怎么设计的，感觉还是拆分表比优化来得快。
建议直接拆分表，简单粗暴效果好
TiDB 本质上是一个分布式关系型数据，对列数会有要求，列越多，意味着读取一行数据的代价越高，随着数据量增加出现性能问题是必然的。
楼主这个问题，和用户画像、用户特征分析、广告标签的数据分析场景比较类似，这个情况解决思路有下面几个：
垂直拆分，根据业务属性不同，在垂直方向上拆分表，减少单行的列数量。控制在官方建议的合理范围内，否则容易出现各种未知问题。
tidb天然支持超大表的存储，有不少用户都有几十亿、上百亿、甚至上万亿行的单表，且能保持不错的读写性能。基于这个特性，可以考虑调整一下表结构设计，采用列转行方式，把列转为行，每个属性一行存储，因为查询时是根据用户维度检索的，所以这个方案查询性能也不会差。
动态属性标签存储，可以考虑使用json替代。性能要提前测试和验证充分。
不用tidb，选择其他支持存储稀疏二维数据的数据库，比如HBASE，等等。