首页
学习
活动
专区
工具
TVP
发布
精选内容/技术社群/优惠产品,尽在小程序
立即前往

数据库查询优化

1 使用SET NOCOUNT ON 选项: 缺省地,每次执行SQL语句时,一个消息会从服务端发给客户端以显示SQL语句影响的行数。这些信息对客户端来说很少有用。通过关闭这个缺省值,你能减少在服务端和客户端的网络流量,帮助全面提升服务器和应用程序的性能。为了关闭存储过程级的这个特点,在每个存储过程的开头包含“SET NOCOUNT ON”语句。 2 正确使用UNION和UNION ALL: 许多人没完全理解UNION和UNION SELECT是怎样工作的,因此,结果浪费了大量不必要的SQLServer资源。当使用UNION时,它相当于在结果集上执行SELECT DISTINCT。换句话说,UNION将联合两个相类似的记录集,然后搜索重复的记录并排除。如果这是你的目的,那么使用UNION是正确的。但如果你使用UNION联合的两个记录集没有重复记录,那么使用UNION会浪费资源,因为它要寻找重复记录,即使你确定它们不存在。 所以如果你知道你要联合的记录集里没有重复,那么你要使用UNION ALL,而不是UNION。UNION ALL联合记录集,但不搜索重复记录,这样减少SQLServer资源的使用,从而提升性能。 3 尽量不用SELECT * : 绝大多数情况下,不要用 * 来代替查询返回的字段列表,用 * 的好处是代码量少、就算是表结构或视图的列发生变化,编写的查询SQL语句也不用变,都返回所有的字段。但数据库服务器在解析时,如果碰到 *,则会先分析表的结构,然后把表的所有字段名再罗列出来。这就增加了分析的时间。 4 慎用SELECT DISTINCT: DISTINCT子句仅在特定功能的时候使用,即从记录集中排除重复记录的时候。这是因为DISTINCT子句先获取结果集然后去重,这样增加SQLServer有用资源的使用。当然,如果你需要去做,那就只有去做了。 当如果你知道SELECT语句将从不返回重复记录,那么使用DISTINCT语句对SQLServer资源不必要的浪费。 5 少用游标: 任何一种游标都会降低SQLServer性能。有些情况不能避免,大多数情况可以避免。所以如果你的应用程序目前正在使用TSQL游标,看看这些代码是否能够重写以避免它们。如果你需要一行一行的执行操作,考虑下边这些选项中的一个或多个来代替游标的使用: 使用临时表 使用WHILE循环 使用派生表 使用相关子查询 使用CASE语句 使用多个查询 上面每一个都能取代游标并且执行更快。 如果你不能避免使用游标,至少试着提高它们的速度,找出加速游标的方法。 6 选择最有效率的表名顺序: SQLSERVER的解析器按照从右到左的顺序处理FROM子句中的表名,因此FROM子句中写在最后的表(基础表driving table)将被最先处理,在FROM子句中包含多个表的情况下,必须选择记录条数最少的表作为基础表,当SQLSERVER处理多个表时,会运用排序及合并的方式连接它们。首先,扫描第一个表(FROM子句中最后的那个表)并对记录进行排序;然后扫描第二个表(FROM子句中最后第二个表);最后将所有从第二个表中检索出的记录与第一个表中合适记录进行合并。 例如: 表 TAB1有 16384 条记录,表 TAB2 有5条记录,选择TAB2作为基础表 (最好的方法): select count(*) from TAB1 a, TAB2 b 选择TAB1作为基础表 (不佳的方法): select count(*) from TAB2 a, TAB1 b 如果有3个以上的表连接查询,那就需要选择交叉表(intersection table)作为基础表,交叉表是指那个被其他表所引用的表。 7 使用表的别名(Alias): 当在SQL语句中连接多个表时,请使用表的别名并把别名前缀于每个Column上,这样可以减少解析的时间并减少那些由Column歧义引起的语法错误。 8 SARG你的WHERE条件: ARGE来源于"Search Argument"(搜索参数)的首字母拼成的"SARG",它是指WHERE子句里,列和常量的比较。如果WHERE子句是sargable(可SARG的),这意味着它能利用索引加速查询的完成。如果WHERE子句不是可SARG的,这意味着WHERE子句不能利用索引(或至少部分不能利用),执行的是全表或索引扫描,这会引起查询的性能下降。 在WHERE子句里不可SARG的搜索条件如"IS NULL", "<>", "!=", "!>", "!<", "NOT", "NOT EXISTS", "NOT IN", "NOT LIKE"和"LIKE '%500'",通常(但不总是)会阻止查询优

02
您找到你想要的搜索结果了吗?
是的
没有找到

ClickHouse深度解析,收藏这一篇就够了~

五、核心概念 5.1.表引擎(Engine) 表引擎决定了数据在文件系统中的存储方式,常用的也是官方推荐的存储引擎是MergeTree系列,如果需要数据副本的话可以使用ReplicatedMergeTree系列,相当于MergeTree的副本版本。读取集群数据需要使用分布式表引擎Distribute。 5.2.表分区(Partition) 表中的数据可以按照指定的字段分区存储,每个分区在文件系统中都是都以目录的形式存在。常用时间字段作为分区字段,数据量大的表可以按照小时分区,数据量小的表可以在按照天分区或者月分区,查询时,使用分区字段作为Where条件,可以有效的过滤掉大量非结果集数据。 5.3.分片(Shard) 一个分片本身就是ClickHouse一个实例节点,分片的本质就是为了提高查询效率,将一份全量的数据分成多份(片),从而降低单节点的数据扫描数量,提高查询性能。 5.4. 复制集(Replication) 简单理解就是相同的数据备份,在CK中通过复制集,我们实现保障了数据可靠性外,也通过多副本的方式,增加了CK查询的并发能力。这里一般有2种方式:(1)基于ZooKeeper的表复制方式;(2)基于Cluster的复制方式。由于我们推荐的数据写入方式本地表写入,禁止分布式表写入,所以我们的复制表只考虑ZooKeeper的表复制方案。 5.5.集群(Cluster) 可以使用多个ClickHouse实例组成一个集群,并统一对外提供服务。 六、主要表引擎深入解析 6.1.TinyLog 最简单的表引擎,用于将数据存储在磁盘上,每列都存储在单独的压缩文件中,写入时,数据附加到文件末尾. 缺点:(1)没有并发控制(没有做优化,同时写会数据会损坏,报错) (2)不支持索引 (3)数据存储在磁盘上 优点:(1)小表节省空间 (2)数据写入,只查询,不做增删改操作创建表: create table stu1(id Int8, name String)ENGINE=TinyLog 6.2. Memory 内存引擎,数据以未压缩的原始形式直接保存在内存中,服务器重启,数据会消失,读写操作不会相互阻塞,不支持索引。建议上限1亿行的场景。优点:简单查询下有非常高的性能表现(超过10G/s) 创建表: create table stu1(id Int8, name String)ENGINE=Merge(db_name, 'regex_tablename') 6.3.Merge 本身不存储数据,但可用于同时从任意多个其他的表中读取数据,读是自动并行的,不支持写入,读取时,那些真正被读取到数据的表的索引(如果有的话)会被占用,默认是本地表,不能跨机器。参数:一个数据库名和一个用于匹配表名的正则表达式 创建表: create table t1(id Int8, name String)ENGINE=TinyLog create table t2(id Int8, name String)ENGINE=TinyLog create table t3(id Int8, name String)ENGINE=TinyLog create table t (id UInt16, name String)ENGINE=Merge(currentDatabase(), ‘^t’) 6.4.MergeTree ck中最强大的表引擎MergeTree(合并树)和该系列(*MergeTree)中的其他引擎。使用场景:有巨量数据要插入到表中,高效一批批写入数据片段,并希望这些数据片段在后台按照一定规则合并。相比在插入时不断修改(重写)数据进行存储,会高效很多。优点:(1)数据按主键排序 (2)可以使用分区(如果指定了主键)(3)支持数据副本 (4)支持数据采样 创建表: ENGINE MergeTree() PARTITION BY toYYYYMM(EventDate) ORDER BY (CounterID, EventDate, intHash32(UserID)) SAMPLE BY intHash32(UserID) SETTINGS index_granularity=8192

02
领券