产品使用过程中遇到的问题及建议
问题：
1.执行计划突然改变导致业务出问题(频率较高影响较大)
2.Tiflash查询优化，Tiflash查询前需要同步所有数据，保证读取到最新的数据，会影响查询效率
3.tidb insert优化，目前在生产环境遇到过一些瓶颈，希望insert能更快
4. 关于调度，没配置label，我这边扩容之后新节点磁盘降的很慢(调大store limit会加快)，老节点磁盘还在快速下降(重点)，并且集群稳定后，各节点磁盘使用量并不平衡
5. 集群中有tikv节点磁盘爆掉之后drop partition未执行
6. cdc下游配置mysql/tidb时，配置的用户没检查权限是否满足要求
7. TiUP元数据怎么备份，目前元数据单份，有一定的风险
现有功能建议
1.加强分区表partition的功能
案例：下推至tiflash的执行计划未做分区裁剪
需求：
- 支持更优的分区裁剪功能，加快查询效率
- 目前mysql规范中，分区键一定要加入到pk/uk中，但是这对业务会有一些侵入性。比如分区键是时间字段，用upsert逻辑更新时间字段会导致多一条数据出来，业务还要先删除原来的数据。需求是upsert也能在原来的数据上直接改。（这个突破了mysql对分区表的定义，或许tiflash/tidb可以支持一种更高级的分区功能）
2.加强算子下推
案例：length、ADDDATE算子未下推至tiflash
需求：
- 案例中的 length, ADDDATE 等算子的下推，特别是和时间处理相关的函数下推，因为分析业务中时间是常用的过滤条件
- 下推能力至少能和tikv持平，即当前tikv能支持的下推，tiflash都需要支持一下，否则tikv就会比tiflash算得快，tiflash就没有使用的理由
- 我们某些特殊的业务，里面用到的json类型，相关的json算子也需要支持下推一下，比如json_length, json_extract…，不限于这些。
3.ddl同步至tiflash
案例: enum类型添加枚举值未同步到tiflash
一个是schema层面上忽略了这个enum的变化，第二个是存储层也不支持这个enum的变化
需求：
4.insert/update/delete/replace select不会走tiflash
案例：replace into select 语句无法走tiflash
需求：
- insert into xxx select from xxx 是很常见的sql业务，这是利用数据库本身的能力做一些简单的类似于物化视图的行为，一个sql同时存在读写，tiflash需要支持这种场景
5.Tiup没对网络打通这一块感觉考虑不足，一般存储服务都在内网，一些功能涉及到内外网或者管理网不通就无法使用了
6.TiUP的设计希望能更贴合一般公司的架构，更方便的接入公司系统。
期望产品新增功能
1.TiDB: 提供智能的表结构优化功能
背景:
- 一些平台化的服务，在后端建表仅会建字段和属性，并不会考虑加索引、sql优化等事情
- 业务侧开发人员水平不齐，会造成一些表未加索引或者索引不够优
- TiUP搞个Console?
社区组织的活动体验
希望能增加一些偏db开发的分享会
对于目前的社区服务体验
很赞
对于目前 TiDB 社区项目的吐槽
1.建议TUG答疑帖与技术文章分开
对于目前 TiDB 社区运营人员的吐槽
无
其他需求和建议
1.是否可以考虑对给开源组件首次提pr的同学安排个mentor
