一、元组是什么？

元组，也叫tuple，这个叫法是很学术的叫法，但是现在数据库中一般叫行或者记录。

二、postgresql的解决方法

在postgresql数据库中既可以手动去清理。也可以运用自动清理参数

自动清理相关参数

在PostgreSQL数据库系统配置文件中，与系统自动清理相关的主要相关参数如下：
autovacuum：是否启动系统自动清理功能，默认值为on。
autovacuum_max_workers：设置系统自动清理工作进程的最大数量。
autovacuum_naptime：设置两次系统自动清理操作之间的间隔时间。
autovacuum_vacuum_threshold和autovacuum_analyze_threshold：设置当表上被更新的元组数的阈值超过这些阈值时分别需要执行vacuum和analyze。
autovacuum_vacuum_scale_factor和autovacuum_analyze_scale_factor：设置表大小的缩放系数。
autovacuum_freeze_max_age：设置需要强制对数据库进行清理的XID上限值。

### 1.查询元祖和那些表需要清理查询当前数据库表已经达到自动清理条件的表及相关信息

SELECT
    c.relname 表名,
    (current_setting('autovacuum_analyze_threshold')::NUMERIC(12,4))+(current_setting('autovacuum_analyze_scale_factor')::NUMERIC(12,4))*reltuples AS 自动分析阈值,
    (current_setting('autovacuum_vacuum_threshold')::NUMERIC(12,4))+(current_setting('autovacuum_vacuum_scale_factor')::NUMERIC(12,4))*reltuples AS 自动清理阈值,
    reltuples::DECIMAL(19,0) 活元组数,
    n_dead_tup::DECIMAL(19,0) 死元组数
    pg_class c 
LEFT JOIN pg_stat_all_tables d
    ON C.relname = d.relname
WHERE
    c.relname LIKE'tb%'  AND reltuples > 0
    AND n_dead_tup > (current_setting('autovacuum_analyze_threshold')::NUMERIC(12,4))+(current_setting('autovacuum_analyze_scale_factor')::NUMERIC(12,4))*reltuples;

 这里可以看这个数据库有4张表需要清理 
2.查询当前正在进行自动清理的表及相关信息
 
查询当前正在进行自动清理的表及相关信息 
SELECT
    c.relname 对象名称,
    l.pid 进程id,
    psa.STATE 查询状态,
    psa.query 执行语句,
    now( ) - query_start 持续时间
    pg_locks l
INNER JOIN pg_stat_activity psa ON ( psa.pid = l.pid )
LEFT OUTER JOIN pg_class C ON ( l.relation = C.oid )
WHERE psa.query like 'autovacuum%' and l.fastpath='f'
ORDER BY query_start asc;
3、查询自动清理的历史统计信息
 
查询自动清理的历史统计信息 
SELECT
    relname 表名,
    seq_scan 全表扫描次数,
    seq_tup_read 全表扫描记录数,
    idx_scan 索引扫描次数,
    idx_tup_fetch 索引扫描记录数,
    n_tup_ins 插入的条数,
    n_tup_upd 更新的条数,
    n_tup_del 删除的条数,
    n_tup_hot_upd 热更新条数,
    n_live_tup 活动元组估计数,
    n_dead_tup 死亡元组估计数,
    -- last_vacuum 最后一次手动清理时间,
    last_autovacuum 最后一次自动清理时间,
    -- last_analyze 最后一次手动分析时间,
    last_autoanalyze 最后一次自动分析时间,
    -- vacuum_count 手动清理的次数,
    autovacuum_count 自动清理的次数,
    -- analyze_count 手动分析此表的次数,
    autoanalyze_count 自动分析此表的次数,
    ( CASE WHEN n_live_tup > 0 THEN n_dead_tup :: float8 / n_live_tup :: float8 ELSE 0 END ) :: NUMERIC ( 12, 2 ) AS "死/活元组的比例"
    pg_stat_all_tables
WHERE
    schemaname = 'public'
ORDER BY n_dead_tup::float8 DESC;
因保密需要，部分数据是虚构的 
手动清理往往在自动清理占时太长 ，清理不彻底的时候才进行手动清理 
数据表收缩
 
VACUUM FULL VERBOSE 表名;
VACUUM FULL VERBOSE ANALYZE 表名;
 清理完之后会提高查询效率，那是经常需要进行插入，update的表需要时刻关注，这种表的所占的空间比较大，需要时常收缩清理 ，当然自动清理会堵塞部分数据库进程。  
最后补一张大佬1_bit做的饭
 
                                    刚熟悉PG的开发者接触PG时,或多或少会碰到一些问题.常见的表现是碰到一些慢SQL.这时候别急着吐槽.绝大多数并不是问题,稍微的语法调整或进行一些简单的优化就能解决问题.下面具体分析几个案例.一: 中文字符串的索引扫描慢test =# \d testidx Table"test.testidx" Column | Type...
select * from int_twilio_twilionumber where merchant_id = 1234 and active = true and "default"=true
order by date_created limit 1
这个查询竟然发了2-3分钟无法回复。
1. 查看表大小 800MB：， 表记录大概4000条。
SELEC...
                                    查看当前数据库的所有表和表的触发器函数的依赖关系，只显示依赖于其他函数的函数，按依赖关系排序，只显示函数名和参数类型。– 查看当前数据库的所有表和表的触发器函数的依赖关系，只显示依赖于其他函数的函数，按依赖关系排序。– 查看当前数据库的所有表和表的触发器函数的依赖关系，只显示依赖于其他函数的函数。– 查看当前数据库的所有表和表的触发器函数的依赖关系。– 查看当前数据库的所有表和表的触发器函数的源代码。– 查看当前数据库的所有表和表的触发器函数。– 查看当前数据库的所有表和表的触发器。
    PG的配置文件是数据库目录下的postgresql.conf文件，8.0以后的版本可支持K，M，G这样的参数，只要修改相应参数后重新启动PG服务就OK了。shared_buffers：这是最重要的参数，postgr...
复制过来的一定发现语句好怪,对的,这就是pgsql,接下来就开始了
1,你的把’public’.全部替换成空;
2,对于字段的说明不能是 COMMENT ON COLUNN  “XXX” IS “XXX” 这种方式要改成mysql 的COMMENT
3,postgresqlz中的一些函数
                                    1、Create Index Directly
2、Change Conditions to Use Index
3、尽量避免在where子句中对字段进行运算，导致查询规划器放弃使用index
4、尽量避免在where子句中对字段类型进行强制转换，导致查询规划器放弃使用index
5、少用outer join，减少不必要的sub-query层级数【在不影响得到正确结果的前提下】
6、坚决避免select * 和 redundant columns【多余字段】
7、Index on Expressions
8、Partial Indexes
9、Decompose DDL【分解DDL】
10、Comprehensive optimization【综合优化】
11、索引的创建
12、查找需要删除的索引
13、查找重复的索引
14、查找需要维护的索引，并自定创建索引维护SQL
15、一个index size影响query plan的例子
                                    问题：用postgresql数据库pgrouting插件开发的最短路径规划服务，两个月来一直正常运行，今天突然变得很慢了起来。
问题排查：
1、首先路网数据没有修改，排除数据问题;
2、查看各结点服务器服务正常，排除服务问题;
3、查看数据库运行状态，也正常，排降数据库程序问题;
4、查看系统，CPU资源正常，硬盘空间正常，但发现异常内存快满了，如下图所示：
尝试解决：杀掉占内存的无用进程或增加内存，本次解决方案将占内存大的mysql数据库占用的内存调小。
结果：最短路径规划服务速度恢复正常。
结论：pos