- 功能/改进说明 ：支持 Lock tables 语句，提供表锁
- 为什么需要这个功能/改进 ：TiDB集群拆分/迁移场景下，需要在源端锁定待迁移表（LOCK TABLES t1 WRITE, t2 WRITE）阻止写入，等数据验证完毕写入流量迁移完毕后，再释放锁
- 其他数据库对应功能 ：MySQL的Lock tables
期待改善的一些点：
- 功能：
- TiUP集成进DashBoard，对用户提供API，方便业务自建平台
- DashBoard单独部署，不要占用集群性能，不依赖集群（集群挂掉依然可以进行诊断）
- 完善下游Binlog方案
- 提供表：数据、索引的占用空间，提高统计信息的准确度
- 稳定性提升：
- region物理隔离：分裂、合并、调度需要扫描keys实现，耗费性能
- 无差别的MVCC：读写放大、降低性能，GC会带来性能抖动
- Compaction：性能抖动
- 热点：降低热点对系统带来的影响（木桶效应，我们当前的木桶短板太低了）
- 故障隔离：一个组件的宕机，理论上不应该影响整个集群的服务（比如PD切换Leader，会让QPS短暂掉底）
- 故障诊断：
- 日志格式不统一，排查问题困难，希望能规范错误代码
- SQL执行的全链路追踪
7 个赞
功能/改进说明:tidb 读写分离，可定具体的tikv节点做读服务，相应tikv节点可异步同步数据，接受可指定延迟。
3 个赞
1、 功能/改进说明： 更多的参数支持全局在线修改，比如：oom-action、mem-quota-query、slow-threshold 为什么需要这个功能/改进： 为了修改慢查询的阀值还需要重启tidb实例，这个有点。。。 其他数据库对应功能： Mysql可以在线修改慢查询阀值、innodb_buffer等
2、
功能/改进说明：
tidb的慢日志支持pt-online-schema-change做分析入库，目前只支持分析，不支持入库
为什么需要这个功能/改进：
目前大家公司都有慢查询分析系统了，并且大部分都是基于pt-online-schema-change做分析入库的，tidb如果不支持还需要为tidb单独写一套分析入库的程序
其他数据库对应功能：
下面是pt_query_digest分析mysql慢日志并入库的功能
pt_query_digest
–review h=$monitor_db_host,D=$monitor_db_database,t=mysql_slow_query_review
–history h=$monitor_db_host,D=$monitor_db_database,t=mysql_slow_query_review_history
–no-report --limit=0% --charset=utf8
–since “$last_analysis_time”
–filter="$event->{Bytes} = length($event->{arg}) and $event->{hostname}="$host" and $event->{client}=$event->{User} and $event->{user}=$event->{User} and $event->{db}=$event->{DB}" $slowquery_file
3、 功能/改进说明： drainer to kafka支持多个分区，可以按表的主键分区 为什么需要这个功能/改进： 一个分区的话消费端只能同时有一台服务器消费，一个是单独问题一个是并发问题 其他数据库对应功能： 无
4、 功能/改进说明： Tidb兼容更多的Mysql DDL操作，比如：字符集变更、int变varchar，varchar（100）变varchar（10）、 为什么需要这个功能/改进： 因为我们比较依赖DM做Mysql 到Tidb的同步，这些不兼容的话Task同步经常报错，需要投入很多精力处理 其他数据库对应功能： 无
5、 功能/改进说明： DM支持从monogdb同步数据到Tidb，并且支持全量、增量、全量+增量的方式 为什么需要这个功能/改进： 1、方便从MongoDB迁移到tidb，2、可以很方便的把MongoDB的数据接入tidb，在tidb上做多种数据源的分析 其他数据库对应功能： 阿里云开源的datax有这个功能，但是只支持全量迁移
3 个赞
- 功能/改进说明 ：优化小表读取性能，小表指100万记录以下的数据表处理能力。
- 为什么需要这个功能/改进 ：优化应用架构，其实小表在实际的应用中占比也是挺大的，而当前 TiDB 处理小表读取时间大约在100-400ms 之间，而 MySQ 远远小于100ms。
- 其他数据库对应功能 ：MySQ 远远小于100ms
1 个赞
PD加减节点现在是可以不滚动升级集群的
1 个赞
- 功能/改进说明 ：优化热表读取性能，提供数据缓存到内存的功能。
- 为什么需要这个功能/改进 ：部分公共核心表被高频访问，目前是通过缓存到redis实现高性能访问。如果从tidb反复读取，性能差强人意。
- 其他数据库对应功能 ：MySQ 远远小于100ms，redis访问更快。
1 个赞
- 功能/改进说明 ：SQL提交后想取消，退出当前终端，无法准确找到并取消该查询
- 为什么需要这个功能/改进 ：当DBA误操作使用select * 查询一个TB级别的表，无法正常kill掉而导致tidb-server出现OOM。如果是update或者delete语句还可能会出现数据污染的情况。
- 其他数据库对应功能 ：MySQ 退出终端则SQL取消，tidb分布式事务可能需要考虑更加复杂的情况。
- 功能/改进说明 ：建议实现存储过程
- 为什么需要这个功能/改进 ：报表开发中存储过程的使用还是很方便的，比外部脚本靠谱。而且，实现存储过程的很多要素实际上已经具备了。
- 其他数据库对应功能 ：MySQL 存储过程
1 个赞
- 功能/改进说明 ：DM 部署配置项比较多
- 为什么需要这个功能/改进 ：部署可以跟集群一起，配置项类似tiup 放在一个文件里
- 其他数据库对应功能 ：其他数据库木有
1 个赞
- 功能/改进说明 ：增加审计/操作日志, 把审计日志写入到TiDB 表或者本地日志. 允许指定各种 filters: 用户名, 命令类型等.
- 为什么需要这个功能/改进 ：审计需求. 一般的系统都需要收集超级用户操作日志; 金融系统需要更全面的日志.
- 其他数据库对应功能 ：Percona Server for MySQL 5.5 开始支持 audit log plugin; 5.7 支持audit 过滤.
2 个赞
- 功能/改进说明 ：binlog 消费组件可以支持直接打到canal，或者binlog组件的整合
- 为什么需要这个功能/改进 ：binlog组件下游消费链路过长，配置容易出问题，排查问题不方便
- 其他数据库对应功能 ：其他数据库木有，mysql的binlog解析工具有很多
- 功能/改进说明 ：默认配置3个kv副本，1个tiflash副本。
- 为什么需要这个功能/改进 ：系统运行一段时间，发现AP类查询慢日志较多，自动转换表到tiflash的副本，优化查询
- 其他数据库对应功能 ：其他数据库木有
2 个赞
-
功能/改进说明 ：线上配置建议强制不同组件指定不同路径部署，扩容也必须指定完整
-
为什么需要这个功能/改进 ：减少混部署资源配置不合理，影响使用和维护
-
其他数据库对应功能 ：其他数据库木有
-
功能/改进说明 ：Dashboard 的权限隔离，访问信息快照，审计功能
-
为什么需要这个功能/改进 ：制定规则，或者是提供接口模版，方便和公司内部的管理系统集成
-
其他数据库对应功能 ：其他数据库木有
功能/改进说明：AP类SQL执行时间比较长，希望执行过程中有进度输出，当前sql执行过程中相当于卡住，没有任何信息输出
为什么需要这个功能/改进：AP类SQL经常跑分钟级，需要通过输出判断执行情况，使用更友好
其他数据库对应功能：hive、presto、sparksql等
- 功能/改进说明 ：实现存储过程和触发器
- 为什么需要这个功能/改进 ：公司里这两个东西用的比较多
- 其他数据库对应功能 ：oracle,mysql 储过程和触发器
- 功能/改进说明 ：支持批量添加列，添加索引，有损变更等DDL操作
- 为什么需要这个功能/改进 ：尝试上一些tp业务，开发反馈表结构变更太不方便，列（索引）只能一个一个加，不能一条DDL语句执行。还有如果将varchar（100）改为varchar（50）也不支持，或者是int类型改为varchar，这些有损变更希望能支持。因为业务逻辑可能存在多变，表结构经常会跟着改
- 其他数据库对应功能 ：mysql这些是常规操作
1 个赞
- 功能/改进说明 ：多副本宕机时，支持一键恢复集群，可以先记录可能丢失数据的region信息，后续可以通过先前的备份找回数据
- 为什么需要这个功能/改进 ：当前如果有多副本宕机时，某些失去多数派peer的Region会不可用，手动恢复比较机械，而且时间较长。在用户接受可能数据丢失风险的情况下，可以一键恢复集群，避免某些Region长时间不可访问
- 其他数据库对应功能 ：不清楚
+1 支持