postgreSQL 杂论(索引,查询计划,pg_catalog,查重,去重)
2017-01-10 00:00
197 查看
摘要: 索引,查询计划,pg_catalog,查重,去重
--正常情况下Postgresql建立普通btree索引时会阻塞DML(insert,update,delete)操作,
--直到索引完成,期间读操作不受阻塞。当只有一个用户操作这当然没问题,但是在生产环境,
--并发比较高的情况下,特别是大表建索引就不能这么操作了,不然用户要跳起来骂娘了,
--点个按钮一天还没反应过来。
--使用
--Postgresql提供了一个参数,可以在线建立索引的时候避免因写数据而锁表,
--这个参数叫concurrently。使用很简单,就是用create index concurrently来代替create index即可。
--副作用
--当然了,使用这个参数是有副作用的,不使用这个参数建索引时DB只扫描一次表,
--使用这个参数时,会引发DB扫两次表,同时等待所有潜在会读到该索引的事务结束,有点类似增量索引,
--这么一来,系统的CPU和IO,内存等会受一些影响,所以综合考虑,仍然让用户自行选择,而不是默认。
--失败
--在使用concurrently参数建索引时,有可能会遇到失败的情况,比如建唯一索引索引发现数据有重复,
--又或者用户发现建索引时建错字段的,取消建索引操作了。
--此时该表上会存在一个索引,这是因为带这个参数的建索引命令一经发出,
--就首先会在系统的日志表里先插一个索引记录进去,又因为这个索引最终建失败了,所以会被标记一个INVALID的状态
---索引类型:B-Tree、Hash、GiST和GIN
---1、B-Tree索引主要用于等于和范围查询,默认B-Tree
---2、散列(Hash)索引只能处理简单的等于比较
---3、GiST索引不是一种单独的索引类型,而是一种架构,可以在该架构上实现很多不同的索引策略。
--从而可以使GiST索引根据不同的索引策略,而使用特定的操作符类型
---4、GIN索引是反转索引,它可以处理包含多个键的值(比如数组)。与GiST类似,GIN同样支持用户定义的索引策略
---pg的唯一索引认为所有的 null 不等
---表达式索引:
--非TEXT类型转换为TEXT类型
---部分索引(partial index)是建立在一个表的子集上的索引
--###在B-Tree类型的复合索引中,该索引字段的任意子集均可用于查询条件,
--###不过,只有当复合索引中的第一个索引字段(最左边)被包含其中时,才可以获得最高效率。
----索引的使用建议
-- 总是先运行ANALYZE
-- 使用真实的数据做实验
-- 如果索引没有得到使用,那么在测试中强制它的使用也许会有些价值
-- 使用EXPLAIN ANALYZE命令检查强制使用
-- 表中数据大量变化的时候建议执行VACUUM ANALYZE
-----explain analyze ---------
--评估时间是(磁盘页seq_page_cost)+(扫描行cpu_tuple_cost)默认seq_page_cost是1.0,cpu_tuple_cost是0.01
---relkind是类型,r是自身表,i是索引index;
-----分析步骤
其他查询:
关于看explain analyze的查询:
---relkind是类型,r是自身表,i是索引index;
---reltuples是项目数(行数)(与实际不一定相符,一般略小)
---relpages是所占硬盘的块数
--正常情况下Postgresql建立普通btree索引时会阻塞DML(insert,update,delete)操作,
--直到索引完成,期间读操作不受阻塞。当只有一个用户操作这当然没问题,但是在生产环境,
--并发比较高的情况下,特别是大表建索引就不能这么操作了,不然用户要跳起来骂娘了,
--点个按钮一天还没反应过来。
--使用
--Postgresql提供了一个参数,可以在线建立索引的时候避免因写数据而锁表,
--这个参数叫concurrently。使用很简单,就是用create index concurrently来代替create index即可。
--副作用
--当然了,使用这个参数是有副作用的,不使用这个参数建索引时DB只扫描一次表,
--使用这个参数时,会引发DB扫两次表,同时等待所有潜在会读到该索引的事务结束,有点类似增量索引,
--这么一来,系统的CPU和IO,内存等会受一些影响,所以综合考虑,仍然让用户自行选择,而不是默认。
--失败
--在使用concurrently参数建索引时,有可能会遇到失败的情况,比如建唯一索引索引发现数据有重复,
--又或者用户发现建索引时建错字段的,取消建索引操作了。
--此时该表上会存在一个索引,这是因为带这个参数的建索引命令一经发出,
--就首先会在系统的日志表里先插一个索引记录进去,又因为这个索引最终建失败了,所以会被标记一个INVALID的状态
---索引类型:B-Tree、Hash、GiST和GIN
---1、B-Tree索引主要用于等于和范围查询,默认B-Tree
---2、散列(Hash)索引只能处理简单的等于比较
---3、GiST索引不是一种单独的索引类型,而是一种架构,可以在该架构上实现很多不同的索引策略。
--从而可以使GiST索引根据不同的索引策略,而使用特定的操作符类型
---4、GIN索引是反转索引,它可以处理包含多个键的值(比如数组)。与GiST类似,GIN同样支持用户定义的索引策略
---pg的唯一索引认为所有的 null 不等
---表达式索引:
--CREATE INDEX test1_lower_col1_idx ON test1 (lower(col1)); --CREATE INDEX people_names ON people ((first_name || ' ' || last_name));
--非TEXT类型转换为TEXT类型
--create index idx_test_id on test using btree (( id::TEXT));
---部分索引(partial index)是建立在一个表的子集上的索引
--CREATE INDEX access_log_client_ip_ix ON access_log(client_ip) WHERE NOT (client_ip > inet '192.168.100.0' AND client_ip < inet '192.168.100.255'); --CREATE INDEX orders_unbilled_index ON orders(order_nr) WHERE billed is not true;
--###在B-Tree类型的复合索引中,该索引字段的任意子集均可用于查询条件,
--###不过,只有当复合索引中的第一个索引字段(最左边)被包含其中时,才可以获得最高效率。
----索引的使用建议
-- 总是先运行ANALYZE
-- 使用真实的数据做实验
-- 如果索引没有得到使用,那么在测试中强制它的使用也许会有些价值
-- 使用EXPLAIN ANALYZE命令检查强制使用
-- 表中数据大量变化的时候建议执行VACUUM ANALYZE
-----explain analyze ---------
--评估时间是(磁盘页seq_page_cost)+(扫描行cpu_tuple_cost)默认seq_page_cost是1.0,cpu_tuple_cost是0.01
select relname, relkind, reltuples, relpages from pg_class where relname LIKE '表名'; ---表统计信息
---relkind是类型,r是自身表,i是索引index;
---reltuples是项目数(行数)(与实际不一定相符,一般略小)
---relpages是所占硬盘的块数
-----分析步骤--explain select * from dba.website ; ----explain (analyze,verbose,costs,timing,buffers) --select relpages,reltuples from pg_class where relname = 'website'; -- show cpu_tuple_cost ; -- show seq_page_cost; -- cost = relpages * seq_page_cost + reltuples * cpu_tuple_cost
其他查询:
select pg_relation_size('inx_da_loan_data_201704_date_loan')/1024 || 'K' AS size; ---查看索引占用空间 select * from pg_class; ---记录数据表、索引(仍然需要参阅pg_index)、序列、视图、复合类型和一些特殊关系类型的元数据 select * from pg_namespace; ---存储名字空间(模式) select * from pg_type ; ---存储数据库所有的类型+表 select * from pg_attribute ; ---存储所有表(包括系统表,如pg_class)的字段信息 select * from pg_attrdef; ---存储字段缺省值 select * from pg_authid ; ---存储有关数据库认证的角色信息 select * from pg_auth_members ; ---储角色之间的成员关系 select * from pg_constraint ; ---存储PostgreSQL中表对象的检查约束、主键、唯一约束和外键约束 select * from pg_tablespace ; ---存储表空间的信息 select * from pg_database; ---存储数据库的信息 select * from pg_index ; ---索引的一部分信息 select * from pg_tables; ---存储所有的表 select * from pg_indexes; ---提供对数据库中每个索引的有用信息的访问 select * from pg_views; ---提供对数据库里每个视图的有用信息的访问途径 select * from pg_user; ---提供对数据库用户的相关信息的访问 select * from pg_roles; ---提供访问数据库角色有关信息的接口 select * from pg_rules; ---提供对查询重写规则的有用信息访问的接口 select * from pg_settings; ---提供对服务器运行时参数的访问
关于看explain analyze的查询:
select relname, relkind, reltuples, relpages from pg_class where relname LIKE '表名'; ---表统计信息
---relkind是类型,r是自身表,i是索引index;
---reltuples是项目数(行数)(与实际不一定相符,一般略小)
---relpages是所占硬盘的块数
select * from pg_tables where schemaname = 'pg_catalog'; ---查看pg数据库原有的表
--去重复(CTID换为要去掉重的字段,CDATA 换为要去重的表名) DELETE FROM CDATA WHERE CTID NOT IN ( SELECT MIN(CTID) FROM CDATA C GROUP BY C.DATA_ID ) --查询重复 select * FROM CDATA WHERE CTID IN ( SELECT MIN(CTID) FROM CDATA C GROUP BY C.DATA_ID )
相关文章推荐
- 第二百八十八节,MySQL数据库-索引、limit分页、执行计划、慢日志查询
- PostgreSQL中主键索引为什么不能被查询利用到?---索引使用情况一例
- PostgreSQL服务过程中的那些事二:Pg服务进程处理简单查询二:SQL解析为parsetree
- mongo 索引查询计划
- PostgreSQL服务过程中的那些事二:Pg服务进程处理简单查询梗概
- postgresql 函数索引优化查询速度
- PostgreSQL查询计划中的路径-BitmapHeapPath-辨析
- 利用pg_trgm的gist和gin索引加速字符匹配查询
- PostgreSQL服务过程中的那些事二:Pg服务进程处理简单查询六:执行器执行
- PostgreSQL的查询语句的连接方式与查询计划比较--简单语句
- 浅析SQL Server的聚焦使用索引和查询执行计划
- 转载:PostgreSQL服务过程中的那些事二:Pg服务进程处理简单查询六:执行器执行
- PostgreSQL的查询语句的连接方式与查询计划比较--多表连接(一)
- PostgreSQL的查询语句的连接方式与查询计划比较--多表连接(二)
- PostgreSQL的查询语句的连接方式与查询计划比较--多表连接(三)
- SQL Server-聚焦使用索引和查询执行计划(五)
- 浅析SQL Server的聚焦使用索引和查询执行计划
- 优化 SQL Server 查询性能----分析执行计划,索引与索引视图,如何识别要优化的查询
- MYSQL-基础操作-索引与查询执行计划
- 高性能可扩展mysql(执行计划,索引分析优化改写,删除重复数据,区间统计,满查询日志)