TIFLASH sql优化问题

🪐 TiDB 技术问题
1

【 TiDB 使用环境】生产环境 /测试/ Poc
【 TiDB 版本】
【复现路径】做过哪些操作出现的问题
【遇到的问题：问题现象及影响】
我们新部署了2个节点tiflash添加了一些表的tiflash副本做测试。发现有个大表的sql查询和之前走tikv速度差不多（甚至还不如tikv快），不知是这个表数据的问题还是SQL优化的问题（因为这个表数据是从原来的老tidb上br备份过来的数据数据量大概60亿）

我们的SQL大都类似这样：
select * from t1 where t1.a in (v1,v2,v3,v4,v5.......)

列子：
SELECT COUNT('*') AS `__count` FROM `xpost`  WHERE (`xpost`.`entryid` IN (4852480, 4852097, 4849282, 4855686, 4849799, 4849160, 4853516, 4852797, 4851728, 4850328, 4851609, 4849052, 4848542, 4854815, 4848160, 4855201, 4855076, 4853029, 4855089, 4851496, 4848681, 4852401, 4849330, 4856371, 4852190, 4851514, 4854986, 4851392, 4852384, 4851522, 4855748, 4851526, 4852306, 4855624, 4855626, 4848589, 4852045, 4848849, 4848594, 4855635, 4852308, 4855766, 4849495, 4855408, 4855134, 4848864, 4850320, 4852305, 4852841, 4857706, 4849261, 4857454, 4852079, 4851696, 4852392, 4846035, 4851956, 4852350, 4848247, 4849274, 4849403, 4848253, 4856062) AND (1) AND `xpost`.`is_comment` = 1 AND `xpost`.`hidden` IN (-2, -1, 0, 2, 3, 4) AND `xpost`.`sourcetype` IN (18) AND ((lower(domain) like '%抖音%')));

我看文档里面有说这种 SELECT IN (SELECT ) 的可以改为 select join的，我这种IN 里面是固定的怎么优化呢？
还有我们的SQL默认都不走tiflash，通过 手动HINT，/*+ read_from_storage(tiflash[table_name]) */ ，可以走tiflash

2

tiflash是列存，你查的条件不在索引上才明显快吧

3

我看了你的sql有很大问题 为啥左边用函数

4

你这种sql如果查询条件里面在tikv上有索引且过滤出的行数不是特别多的情况下，肯定走tikv索引更好，走tiflash性能优化一般。

5

能直接帮我优化下我发的SQL列子吗？最好直接发我优化好的SQL，我不太懂 :rofl: :rofl:

8

不需要优化啊，如果你的sql都是这样的，并且条件字段都有索引，那没必要用tiflash了，现在就已经是优化后的了

9

好的。

10

我的建表语句

CREATE TABLE `xpost` (
  `postid` bigint(20) NOT NULL AUTO_INCREMENT,
  `facetid` int(10) NOT NULL,
  `entryid` int(10) NOT NULL,
  `title` varchar(255) NOT NULL DEFAULT '',
  `url` varchar(512) NOT NULL,
  `abstract` text DEFAULT NULL COMMENT '摘要',
  `click` int(11) DEFAULT '0' COMMENT '点击/阅读',
  `reply` int(11) DEFAULT '0' COMMENT '回复/评论',
  `repost` int(11) DEFAULT '0' COMMENT '转发',
  `praise` int(11) DEFAULT '0' COMMENT '点赞',
  `collect` int(11) DEFAULT '0' COMMENT '收藏',
  `watch` int(11) DEFAULT NULL,
  `wordscount` int(11) DEFAULT '0' COMMENT '字数',
  `keywordcount` int(11) DEFAULT NULL,
  `siteid` int(11) DEFAULT '0',
  `domain` varchar(60) DEFAULT '',
  `author` varchar(60) DEFAULT '',
  `author_id` varchar(60) DEFAULT '' COMMENT '作者ID',
  `posttime` datetime NOT NULL,
  `include_t` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '入库时间',
  `type` tinyint(4) DEFAULT '0' COMMENT 'positive/negtive/neutrual',
  `source` int(11) DEFAULT '0',
  `hidden` tinyint(4) NOT NULL DEFAULT '0' COMMENT '-3；识别噪音，-2:恢复误删数据, -1:已处理, 0: 未处理, 1:已删除, 2:正文噪音, 3:歧义噪音, 4:列表页噪音',
  `sourcetype` tinyint(4) NOT NULL,
  `crisis_post` tinyint(4) NOT NULL DEFAULT '0',
  `ontop` tinyint(4) NOT NULL DEFAULT '0' COMMENT '是否标记，0否1是',
  `type_rank` tinyint(4) NOT NULL DEFAULT '0' COMMENT '正负面可信度',
  `noise_rank` tinyint(4) NOT NULL DEFAULT '0' COMMENT '噪音可信度',
  `device` varchar(60) DEFAULT '' COMMENT '发布设备',
  `is_origin` tinyint(4) NOT NULL DEFAULT '0' COMMENT '是否原创   0：未知，1；原创，2：转载',
  `is_top` tinyint(4) NOT NULL DEFAULT '0' COMMENT '是否头条   0：未知，1；是，2：否',
  `media_type` tinyint(4) NOT NULL DEFAULT '0' COMMENT '媒体类型   0：未知，1；传统媒体，2：自媒体',
  `author_type` tinyint(4) NOT NULL DEFAULT '0' COMMENT '作者类型   0：未知，1；KOL，2：官微  3：水军',
  `content_type` tinyint(4) NOT NULL DEFAULT '0' COMMENT '内容类型   0：未知，1；PGC(营销声量)，2：UGC(自然声量)',
  `client_type` tinyint(4) NOT NULL DEFAULT '0' COMMENT '网站来源   0：未知，1；网页端，2：移动端',
  `industry` varchar(60) DEFAULT '' COMMENT '行业',
  `tags` text DEFAULT NULL,
  `post_type` tinyint(4) DEFAULT '0' COMMENT '内容类型   0：未知，1；PGC，2：UGC',
  `type_reason` varchar(256) DEFAULT '' COMMENT '正负面规则命中原因',
  `update_time` datetime DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '更新时间',
  `origin_source` varchar(64) DEFAULT '' COMMENT '转载来源',
  `media_id` int(11) DEFAULT '0' COMMENT '媒体库ID',
  `w_level` tinyint(1) NOT NULL DEFAULT '0' COMMENT '预警等级',
  `sid` bigint(20) DEFAULT NULL COMMENT '爬虫唯一标识字段',
  `location` varchar(255) DEFAULT '' COMMENT '文章提到的区域',
  `is_comment` tinyint(4) DEFAULT '0',
  `pos_type_rank` int(11) NOT NULL DEFAULT '0' COMMENT '正面可信度',
  `text` text DEFAULT NULL,
  `spider_time` datetime DEFAULT NULL COMMENT '抓取时间',
  `process_time` datetime DEFAULT NULL COMMENT 'upload_to_community开始处理的时间',
  `tidb_in_time` datetime DEFAULT CURRENT_TIMESTAMP COMMENT '真正上到tidb的时间，和incude_t有所差别，include_t是代码的最后的时间',
  PRIMARY KEY (`postid`) /*T![clustered_index] CLUSTERED */,
  UNIQUE KEY `idx_fid_url` (`facetid`,`url`),
  UNIQUE KEY `postid` (`postid`),
  KEY `idx_xpost_url` (`url`(255)),
  KEY `idx_xpost_entryid` (`entryid`),
  KEY `idx_xpost_type` (`type`),
  KEY `idx_xpost_sourcetype` (`sourcetype`),
  KEY `idx_xpost_pt` (`posttime`),
  KEY `idx_xpost_source` (`source`),
  KEY `idx_fid` (`facetid`),
  KEY `idx_xpost_hidden` (`hidden`)
)
11

tiflash会自动优化，它会将在tiflash运行快的语句在自己执行，否则交给tikv

12

大佬的意思是： 不管用tikv还是tiflash，都不用优化SQL，tidb会自动优化是吗？

13

tidb不会对sql进行优化，它针对不同的sql语句决定在tiflash还是tikv中执行

14

不优化好

15

那结论就是：我的SQL走tiflash反而变慢了，那就是我的SQL不适合用tifalsh吗？
有没有办法让他走tiflash变快呀？

16

执行计划发出来看下