“我的 TiDB 听我的”活动开启：你的需求，就是我们努力的方向

🌞 建议反馈 产品需求
42
  1. 功能/改进说明 ： 支持修改字段类型，比如int到varchar
  2. 为什么需要这个功能/改进 ： 常规变更
  3. 其他数据库对应功能 ：基本都支持
3 个赞
43

功能/改进说明 ： tidb 能不能集成类似sharedingsphere功能 后端可以有多套tikv 根据重要性区分一下 （OLTP OLAP） 允许关联查询 允许跨tikv集群 insert select快速迁移数据 每个db可以指定 对应后端其中一个tikv集群 为什么需要这个功能/改进 ： 实现存储冷热分离（故障迁移影响小一些）或者跨区域冷热分离 TA（事务分析）分离
其他数据库对应功能 ：sharedingsphere 支持后端多个数据库

44
  1. 功能/改进说明 ：支持 match against 匹配 逗号分隔的字符串，用于做无限级团队数据统计。 如：
#表结构
CREATE TABLE `usertree` (
 `userid` int(8) unsigned NOT NULL COMMENT '用户ID',
 `username` varchar(20) NOT NULL COMMENT '用户名',
 `parenttree` varchar(1024) NOT NULL DEFAULT '' COMMENT '父亲树',
 PRIMARY KEY (`userid`),
 FULLTEXT KEY `ft_idx_username_parenttree` (`username`,`parenttree`),
 FULLTEXT KEY `ft_idx_parenttree` (`parenttree`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='用户关系树';

#插入数据：
INSERT INTO usertree(`userid`, `username`, `parenttree`) VALUES (10086, '我自己的名字', ''),(10011, 'lv1_1', '10086'),(10012, 'lv1_2', '10086'),(10013, 'lv1_3', '10086'),(20020, 'lv2_1', '10086,10011');

#查询语句：
#1.可匹配 uid:10086 的所有下级用户：
select userid from usertree where MATCH(parenttree) against(10086 IN BOOLEAN MODE);

#2.可匹配 uid:10086自己 和 他的所有下级用户：
select userid from usertree where MATCH(username,parenttree) against('"我自己的名字" 10086' IN BOOLEAN MODE);
  1. 为什么需要这个功能/改进 ：可以方便的匹配 用户团队 join 其他业务表，做报表类统计， 在未支持 CTE 的情况下 效率仅次于 递归CTE
  2. 其他数据库对应功能 ：MySQL 支持这个功能
1 个赞
45

Hi，感谢提议，该功能已经在 TiDB v3.0.9 支持了：https://pingcap.com/docs-cn/stable/releases/3.0.9/

46

感谢建议~ TiDB 正在实现一版 Sequence 的功能~ 欢迎加入 slack channel 进行讨论 tidbcommunity.slack.com #wg-tidb-sequence

1 个赞
47

加入不了 提示只能有pingcap邮箱才能加入:joy:

1 个赞
48

请使用这个链接注册哈：pingcap.com/tidbslack

1 个赞
49
  • 功能/改进说明 ： 支持倒序索引
  • 为什么需要这个功能/改进 ： 互联网企业经常会遇到按照时间从新到旧进行翻页 现在tidb不支持倒序索引 在数据量一大的情况下 正序索引导致的读放大非常严重
  • 其他数据库对应功能 ：mysql 8.0
2 个赞
50

“临时表” 具体指什么？

51

这个功能在最新 master 分支上已经完成了，可以通过把系统变量 “tidb_enable_index_merge” 打开或者使用 SQL hint USE_INDEX_MERGE 试用这个功能；

1 个赞
52

其实就是 内存 临时 持久化，避免 oom。

53

中间计算结果的内存？

54

这个在3.1.0-beta分支是不存在的吗？我看文档上有，但是执行的时候没用

55

这个功能只在 master 上有，文档后续我们修正一下，感谢指正。

56

感谢提议，这个功能会在 4.0 支持，请期待

57

这个功能已经在 TiDB 3.1 版本中支持了，可以通过 BR 工具进行快速的物理备份和恢复，使用文档：使用 BR 进行备份与恢复

58

这个正在做 Incubating Program: Follower Read With Applied Index

59

Follower read 的基础上支持 local read。

没明白这个需求，follower read 除了发一个 req 到 leader 问下信息后面都是 local read

60

RawKV 支持备份恢复

虽然目前有 PR 来对 RawKV 继续备份，但是知乎和一点资讯在提一个 VerKV 的 RFC，支持单行多版本的 KV，能进行全量和增量备份，应该能更好地满足更多场景。

61

你好～请问下这个 region-transfer 与 split 的影响是怎么确认的呢，当时详细的分析可以分享一下吗。一般 split 和 transfer 都是很快的操作，对于业务影响不会很大，我们在内部环境中也有随机调度的干扰测试，你的情况可能和我们预期不太一样，可以具体分享下你那边的场景以及使用的版本。如果不进行split 会导致单个 region 过大，在进行负载均衡的时候也会导致很大的 snapshot， 而且对于随机的写入的话，通过split 和负载均衡增加并发度和集群利用率，提高性能。

ps：OB会在每天晚上低峰期做增量数据与基线数据合并。这部分说的是类似 compaction 的操作 吗，在业务低峰进行 compaction 从而减少对业务的影响