GreenPlum的SQL优化方案
PostgreSQL数据库调优经验
PostgreSQL数据库调优经验一、概述数据库的性能优化对于提升系统的整体性能至关重要。
本文将介绍一些PostgreSQL数据库调优的经验和技巧，旨在帮助开发人员和管理员提升数据库的性能和效率。
二、硬件调优1. 存储设备选择：选择高速且稳定的存储设备，如SSD硬盘，以提高数据库的读写性能。
2. 内存设置：合理设置shared_buffers参数，将其调整到适当的大小，以便缓存更多的数据块，提高查询的响应速度。
3. CPU设置：根据服务器的负载情况，调整max_connections参数以控制并发连接数，在高负载情况下可以考虑增加系统的CPU核心数。
三、索引优化1. 使用合适的索引：根据查询的需求和表的大小，选择合适的索引类型（B树、哈希、GiST等），并确保创建索引的列具有高选择性。
2. 删除不必要的索引：定期审查并删除不再使用或无效的索引，以减少索引维护的开销。
3. 索引覆盖：通过创建索引包含所需的查询列，减少磁盘I/O，提高查询的性能。
四、查询优化1. 避免全表扫描：使用WHERE子句和索引来过滤数据，避免全表扫描的开销。
2. 使用合适的JOIN类型：根据数据之间的关联关系，选择合适的JOIN类型（INNER JOIN、LEFT JOIN、OUTER JOIN等），以减少查询的复杂度。
3. 分解复杂查询：对于复杂的查询，可以将其分解为多个简单的查询，并使用临时表或WITH语句组合结果，以提高查询的可维护性和性能。
五、配置优化1. 文件系统设置：使用合适的文件系统（如XFS、EXT4等）以及正确的文件系统参数，提高I/O性能。
2. 日志设置：根据实际需求，合理设置日志级别和日志记录方式，避免过多的日志输出对性能造成影响。
3. 超时设置：根据业务需求和系统负载情况，调整合适的超时设置，避免长时间的等待或超时导致的性能问题。
六、并发控制1. 事务管理：合理管理事务的提交和回滚，尽量减少长事务的使用，以避免锁定资源时间过长，影响并发性能。
sql优化步骤和优化方法
sql优化步骤和优化方法SQL优化是提高数据库查询性能的重要手段。
通过对SQL语句的优化，可以减少数据库的IO操作，提高查询效率，从而提升整个应用系统的性能。
本文将介绍SQL优化的步骤和方法，帮助读者更好地理解和应用SQL优化技巧。
一、SQL优化的步骤SQL优化的步骤可以分为以下几个阶段：1. 分析查询需求：首先要明确查询的目的和需求，确定要查询的表和字段，以及查询的条件和排序方式。
这对后续的优化工作非常重要。
2. 分析执行计划：执行计划是数据库查询优化的关键，它描述了数据库如何执行查询语句。
通过分析执行计划，可以找到查询语句中存在的性能问题，从而进行优化。
3. 优化查询语句：根据分析执行计划的结果，对查询语句进行优化。
可以从多个方面进行优化，如优化查询条件、优化索引、优化表结构等。
4. 测试和验证：对优化后的查询语句进行测试和验证，确保优化效果符合预期。
二、SQL优化的方法SQL优化的方法有很多，下面介绍几种常用的优化方法：1. 优化查询条件：合理选择查询条件，尽量减少查询结果集的大小。
可以通过使用索引、合理设计查询条件、避免使用模糊查询等方式来优化查询条件。
2. 优化索引：索引是提高查询性能的重要手段。
可以通过合理设计和使用索引，减少数据库的IO操作，提高查询效率。
需要注意的是，索引也会占用存储空间，过多的索引会影响更新操作的性能。
3. 优化表结构：合理设计表的结构，可以减少数据库的IO操作，提高查询性能。
可以通过拆分大表、合并小表、使用分区表等方式来优化表结构。
4. 避免使用子查询：子查询会导致数据库执行多次查询操作，降低查询性能。
可以通过使用连接查询、临时表等方式来避免使用子查询。
5. 避免使用不必要的字段：在查询语句中，只查询需要的字段，避免查询不必要的字段。
可以减少数据库的IO操作，提高查询效率。
6. 合理使用缓存：对于一些查询结果比较稳定的查询语句，可以将查询结果缓存起来，减少数据库的查询操作，提高查询性能。
如何进行SQL调优
如何进行SQL调优SQL调优是优化数据库性能的一个重要步骤。
通常情况下，优化SQL查询的效率会使整个系统的性能得到提升。
在这篇文章中，我们将探讨如何进行SQL调优。
一、分析SQL语句首先，我们需要分析SQL查询语句。
如果SQL查询不正确或不充分，则不可能实现有效的调优。
我们需要了解查询的目的、查询的表、所需的数据以及查询的条件等等。
在分析查询语句时，我们需要关注以下几个方面：1.查询完成的时间是否满足需求；2.过滤条件是否合适；3.表之间的关系是否正确；4.是否使用了合适的索引；5.查询中使用了哪些函数；6.是否将复杂的查询分解为简单的查询；7.是否存在重复数据；8.是否使用了动态语句。
二、优化数据表结构第二个优化策略是优化数据表结构。
优化数据表结构可以使查询更快并减少查询时间。
以下是一些优化数据表结构的建议：1.将表拆分为更小的表；2.对于大型的表，可以使查询更快，更好地维护和管理；3.添加数据到表中时，使用批量插入而不是单独插入；4.为表的主键添加索引；5.使用适当的数据类型；6.删除不必要的列；7.标准化表设计。
三、使用优化查询技术第三个优化策略是使用优化查询技术。
以下是一些优化查询技术的建议：1.使用预编译语句；2.使用存储过程；3.将大的表拆分为小表；4.优化查询过程中使用的函数；5.范围查询的优化技术；6.优化复杂查询；7.熟悉查询缓存的工作原理；8.使用正确的JOIN语句。
四、使用合适的索引使用合适的索引是第四个优化策略。
索引是用于查找表中数据的一种结构。
以下是一些使用索引的建议：1.只有在需要时才使用索引；2.使用准确性为索引提供数据；3.使用索引可以使查询更快，但也会增加插入和修改的时间；4.对于大型表，使用索引可以显著提高性能；5.使用覆盖索引；6.避免使用不规范的索引；7.使用联合索引；8.使用优化查询缓存。
五、优化数据库服务器优化数据库服务器是第五个优化策略。
以下是一些优化服务器的建议：1.选择正确的硬件；2.选择正确的操作系统；3.使用正确的配置参数；4.配置正确的缓存大小；5.使用内存表代替磁盘表；6.合理设置自动增量字段；7.优化写和读的优化区域；8.备份和压缩数据。
Greenplum最佳实践
Greenplum最佳实践⼀、最佳实践数据库参数部分GP数据库参数配置以下配置存于⽂件–postgresql.conf中，仅列出⼀些最常⽤的参数。
shared_buffers：刚开始可以设置⼀个较⼩的值，⽐如总内存的15%，然后逐渐增加，过程中监控性能提升和swap的情况。
effective_cache_size : 这个参数告诉PostgreSQL的优化器有多少内存可以被⽤来缓存数据，以及帮助决定是否应该使⽤索引。
这个数值越⼤，优化器使⽤索引的可能性也越⼤。
因此这个数值应该设置成shared_buffers加上可⽤操作系统缓存两者的总量。
通常这个数值会超过系统内存总量的50%。
work_mem: 当PostgreSQL对⼤表进⾏排序时，数据库会按照此参数指定⼤⼩进⾏分⽚排序，将中间结果存放在临时⽂件中，这些中间结果的临时⽂件最终会再次合并排序，所以增加此参数可以减少临时⽂件个数进⽽提升排序效率。
当然如果设置过⼤，会导致swap的发⽣，所以设置此参数时仍需谨慎，刚开始可设定为总内存的5%。
temp_buffers: 即临时缓冲区，拥有数据库访问临时数据，GP中默认值为1M，在访问⽐较到⼤的临时表时，对性能提升有很⼤帮助。
gp_fts_probe_threadcount: 设置ftsprobe线程数，此参数建议⼤于等于每台服务器segments的数⽬。
gp_hashjoin_tuples_per_bucket: 此参数越⼩，hash_tables越⼤，可提升join性能。
gp_interconnect_setup_timeout: 此参数在负载较⼤的集群中，应该设置较⼤的值。
gp_vmem_protect_limit:控制了每个段数据库为所有运⾏的查询分配的内存总量。
如果查询需要的内存超过此值，则会失败。
使⽤下⾯公式确定合适的值：(swap + (RAM * vm.overcommit_ratio)) * .9 / number_of_Segments_per_server1例如，具有下⾯配置的段服务器：8GB 交换空间128GB 内存vm.overcommit_ratio = 508 个段数据库1234(8 + (128 * .5)) * .9 / 8 = 8 GB，则设置gp_vmem_protect_limit为 8GB：gp_statement_mem:服务器配置参数 gp_statement_mem 控制段数据库上单个查询可以使⽤的内存总量。
一条sql执行过长的时间,你如何优化,从哪些方面入手？
一条sql执行过长的时间，你如何优化，从哪些方面入手？当一条SQL查询执行时间过长时，优化可以从多个方面入手。
以下是一些可能的优化方向：1. 执行计划分析：使用数据库提供的工具分析查询执行计划。
在MySQL中，可以使用EXPLAIN关键字来查看查询的执行计划，了解数据库是如何执行查询的。
通过分析执行计划，可以找到潜在的性能问题，例如是否使用了索引、是否有全表扫描等。
2. 索引优化：确保查询中涉及的列上有适当的索引。
缺乏索引或者使用不当的索引可能导致查询性能下降。
可以考虑创建、调整或删除索引以优化查询性能。
注意，索引并不是越多越好，需要根据具体查询模式和数据分布来合理选择索引。
3. 适当使用缓存：利用数据库缓存，如MySQL的查询缓存或其他缓存机制，可以避免重复执行相同的查询。
但要注意，在某些情况下，查询缓存可能并不总是有益的，因此需要谨慎使用。
4. 分析慢查询日志：启用慢查询日志并分析其中记录的查询，找出执行时间较长的语句。
慢查询日志可以提供有关执行时间、索引使用等方面的信息，有助于定位潜在的性能问题。
5. 表结构优化：检查表的设计，确保表结构符合业务需求。
有时，调整表的结构，如拆分或合并表，可以改善查询性能。
6. 分批处理：如果查询涉及大量数据，考虑使用分页或分批处理的方式，以避免一次性处理大量数据导致的性能问题。
7. 数据库参数调整：调整数据库系统的参数，如连接池大小、内存配置等，以适应查询的需求。
不同的数据库系统有不同的配置参数，需要根据具体情况来调整。
8. 使用合适的数据类型：选择合适的数据类型可以减小存储空间、提高查询效率。
尽量避免在 WHERE 子句中对字段进行函数操作，因为这可能导致索引失效。
9. 数据库版本升级：考虑将数据库升级到最新版本，因为新版本通常包含了性能改进和优化。
在进行优化时，通常需要综合考虑以上多个方面，并根据具体的业务场景和数据特点来制定合适的优化策略。
同时，对于复杂的查询和大规模数据，可能需要结合数据库监控工具来实时监测系统性能。
Greenplum-数据库最佳实践
❖介绍本文介绍Pivotal Greenplum Database数据库（以下简称：Greenplum数据库，或GPDB）的最佳实践。
最佳实践是指能持续产生比其他方法更好结果的方法或者技术，它来自于实战经验，并被证实了遵循这些方法可以获得可靠的预期结果。
本最佳实践旨在通过利用所有可能的知识和技术为正确使用GPDB提供有效参考。
本文不是在教您如何使用Greenplum数据库的功能，而是帮助您在设计、实现和使用Greenplum数据库时了解需要遵循哪些最佳实践。
关于如何使用和实现具体的Greenplum 数据库特性，请参考上的Greenplum数据库帮助文档以及上的Sandbox和实践指南。
本文目的不是要涵盖整个产品或者产品特性，而是概述GPDB实践中最重要的因素。
本文不涉及依赖于GPDB具体特性的边缘用例，后者需要精通数据库特性和您的环境，包括SQL访问、查询执行、并发、负载和其他因素。
通过掌握这些最佳实践知识，会增加GPDB集群在维护、支持、性能和可扩展性等方面的成功率。
第一章最佳实践概述本部分概述了Greenplum数据库最佳实践所涉及的概念与要点。
数据模型GPDB 是一个基于大规模并行处理(MPP)和无共享架构的分析型数据库。
这种数据库的数据模式与高度规范化的事务性SMP数据库显著不同。
通过使用非规范化数据库模式，例如具有大事实表和小维度表的星型或者雪花模式，GPDB在处理MPP分析型业务时表现优异。
跨表关联(JOIN)时字段使用相同的数据类型。
详见数据库模式设计（后续章节)堆存储和追加优化存储(Append-Optimized，下称AO)若表和分区表需要进行迭代式的批处理或者频繁执行单个UPDATE、DELETE或INSERT 操作，使用堆存储。
若表和分区表需要并发执行UPDATE、DELETE或INSERT操作，使用堆存储。
若表和分区表在数据初始加载后更新不频繁，且仅以批处理方式插入数据，则使用AO存储。
gp基础知识
gp基础知识
GP（Greenplum）是一个基于PostgreSQL的开源数据仓库系统，主要用于处理大规模数据分析任务。
它采用Master/Slave架构，具有两个Master节点（一个Primary节点和一个Standby节点）和多个Segment
节点，每个节点上可以运行多个数据库。
GP采用shared nothing架构（MPP），通过内存Cache存储状态的信息，而不在节点上保存状态的信息。
节点之间的信息交互都是通过节点互联网络实现，通过将数据分布到多个节点上来实现规模数据的存储，通过并行查询处理来提高查询性能。
要优化GP系统，需要从全局考虑。
优化建议包括以下几个方面：
1. 硬件层：确保磁盘、主机、网络等硬件健康，OS为GP环境定制调优，
磁盘容量最大使用70%以前，每次dml操作、load数据后都要vacuum。
2. 资源的分配，并发资源竞争：通过资源队列限制gp系统里active queryes的数量，分配给指定query的资源多少，使gp系统最佳状态运行；清楚gp系统的运行负载，把后台管理放(如，data load，vacuum，backup等 )在系统负载低时运行。
3. 统计信息的准确性：确保统计信息准确，以支持查询优化器的正确决策。
4. 数据分布：合理分布数据，避免数据倾斜，以提高查询性能。
5. 数据库的设计：设计合理的数据库模式，包括表结构、索引、分区等。
6. SQL的优化：编写高效的SQL查询语句，利用查询优化器进行查询优化。
以上内容仅供参考，建议咨询数据库领域专业人士获取更准确的信息。
Greenplum优化总结
Greenplum优化总结Greenplum优化总结GP优化需要了解清理缓存、性能监控、执⾏计划分析等知识。
优化主要包含以下四⽅⾯： 表、字段，SQL，GP配置、服务器配置，硬件及节点资源。
⼀、清理缓存：#!/usr/bin/sudo bashgpstop -r #快速停⽌GP数据库sync #清空⾼速缓存前尝试将数据刷新⾄磁盘#释放linux内存echo1 > /proc/sys/vm/drop_cachesecho2 > /proc/sys/vm/drop_cachesecho3 > /proc/sys/vm/drop_cachesgpstart #启动GP数据库⼆、性能监控Performance Monitor Greenplum监控管理平台Pivotal Greenplum Command Center (GPCC)和Pivotal Greenplum (GPDB)。
实际使⽤过程中发现对于6-8秒的查询（单表亿级数据），GPCC反应⽐较慢，CPU、IO等信息为0，可以采⽤其他⽅式实时监控CPU、内存、IO、⽹络等信息。
三、执⾏计划分析 EXPLAIN 会为查询显⽰其查询计划和估算的代价，但是不执⾏该查询。
EXPLAIN ANALYZE除了显⽰查询的查询计划之外，还会执⾏该查询。
EXPLAIN ANALYZE会丢掉任何来⾃SELECT语句的输出，但是该语句中的其他操作会被执⾏（例如INSERT、UPDATE或者DELETE）。
slice、motion GPDB 有⼀个特有的算⼦：移动（ motion ）。
移动操作涉及到查询处理期间在 Segment 之间移动数据。
motion 分为⼴播（ broadcast ）、重分布（ redistribute motion ）、Gather motion。
正是 motion 算⼦将查询计划分割为⼀个个 slice ，上⼀层 slice 对应的进程会读取下⼀层各个 slice 进程⼴播或重分布的数据，然后进⾏计算。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
GreenPlumn的SQL语句查询优化数据库查询预准备1. VACUUM∙vacuum只是简单的回收空间且令其可以再次使用，没有请求排它锁，仍旧可以对表读写∙vacuum full执行更广泛的处理，包括跨块移动行，以便把表压缩至使用最少的磁盘块数目存储。
相对vacuum要慢，而且会请求排它锁。
∙定期执行：在日常维护中，需要对数据字典定期执行vacuum，可以每天在数据库空闲的时候进行。
然后每隔一段较长时间（两三个月）对系统表执行一次vacuum full，这个操作需要停机，比较耗时，大表可能耗时几个小时。
∙reindex:执行vacuum之后,最好对表上的索引进行重建2. ANALYZE∙命令：analyze [talbe [(column,..)]]∙收集表内容的统计信息，以优化执行计划。
如创建索引后，执行此命令，对于随即查询将会利用索引。
∙自动统计信息收集∙在postgresql.conf中有控制自动收集的参数gp_autostats_mode设置，gp_autostats_mode三个值：none、no_change、on_no_stats（默认）o none：禁止收集统计信息o on change：当一条DML执行后影响的行数超过gp_autostats_on_change_threshold参数指定的值时，会执行完这条DML后再自动执行一个analyze 的操作来收集表的统计信息。
o no_no_stats：当使用create talbe as select 、insert 、copy时，如果在目标表中没有收集过统计信息，那么会自动执行analyze 来收集这张表的信息。
gp默认使用on_no_stats，对数据库的消耗比较小，但是对于不断变更的表，数据库在第一次收集统计信息之后就不会再收集了。
需要人为定时执行analyze.∙如果有大量的运行时间在1分钟以下的SQL，你会发现大量的时间消耗在收集统计信息上。
为了降低这一部分的消耗，可以指定对某些列不收集统计信息，如下所示：∙ 1. create table test(id int, name text,note text);上面是已知道表列note不需出现在join列上，也不会出现在where语句的过滤条件下，因为可以把这个列设置为不收集统计信息：1. alter table test alter note SET STATISTICS 0;3. EXPLAIN执行计划显示规划器为所提供的语句生成的执行规划。
∙cost：返回第一行记录前的启动时间，和返回所有记录的总时间（以磁盘页面存取为单位计量）∙rows：根据统计信息估计SQL返回结果集的行数∙width：返回的结果集的每一行的长度，这个长度值是根据pg_statistic表中的统计信息来计算的。
4. 两种聚合方式∙hashaggregate根据group by字段后面的值算出hash值，并根据前面使用的聚合函数在内存中维护对应的列表，几个聚合函数就有几个数组。
相同数据量的情况下，聚合字段的重复度越小，使用的内存越大。
∙groupaggregate先将表中的数据按照group by的字段排序，在对排好序的数据进行全扫描，并进行聚合函数计算。
消耗内存基本是恒定的。
∙选择在SQL中有大量的聚合函数，group by的字段重复值比较少的时候，应该用groupaggregate5. 关联分为三类：hash join、nestloop join、merge join，在保证sql执行正确的前提下，规划器优先采用hash join。
∙hash join: 先对其中一张关联的表计算hash值，在内存中用一个散列表保存，然后对另外一张表进行全表扫描，之后将每一行与这个散列表进行关联。
∙nestedloop:关联的两张表中的数据量比较小的表进行广播，如笛卡尔积：select * fromtest1，test2∙merge join:将两张表按照关联键进行排序，然后按照归并排序的方式将数据进行关联，效率比hash join差。
full outer join只能采用merge join来实现。
∙关联的广播与重分布解析P133，一般规划器会自动选择最优执行计划。
∙有时会导致重分布和广播，比较耗时的操作6. 重分布一些sql查询中，需要数据在各节点重新分布，受制于网络传输、磁盘I/O，重分布的速度比较慢。
∙关联键强制类型转换一般，表按照指定的分布键作hash分部。
如果两个表按照id:intege、id:numericr分布，关联时，需要有一个表id作强制类型转化，因为不同类型的hash值不一样，因而导致数据重分布。
∙关联键与分部键不一致∙group by、开窗函数、grouping sets会引发重分布查询优化通过explain观察执行计划，从而确定如果优化SQL。
1. explain参数显示规划器为所提供的语句生成的执行规划。
∙cost：返回第一行记录前的启动时间，和返回所有记录的总时间（以磁盘页面存取为单位计量）∙rows：根据统计信息估计SQL返回结果集的行数∙width：返回的结果集的每一行的长度，这个长度值是根据pg_statistic表中的统计信息来计算的。
2. 选择合适分布键分布键选择不当会导致重分布、数据分布不均等，而数据分布不均会使SQL集中在一个segment节点的执行，限制了gp整体的速度。
∙使所有节点数据存放是均匀的，数据分布均匀才能充分利用多台机器查询，发挥分布式的优势。
∙join、开窗函数等尽量以分布键作为关联键、分区键。
尤其需要注意的是join、开窗函数会依据关联键、分区键做重分布或者广播操作，因而若分布键和关联键不一致，不论如何修改分布键，也是需要再次重分布的。
∙尽量保证where条件产生的结果集的存储也尽量是均匀的。
∙查看某表是否分布不均：select gp_segment_id,count(*) from fact_tablegroup by gp_segment_id∙在segment一级，可以通过select gp_segment_id,count(*) from fact_table group by gp_segment_id的方式检查每张表的数据是否均匀存放∙在系统级，可以直接用df -h 或du -h检查磁盘或者目录数据是否均匀∙查看数据库中数据倾斜的表首先定义数据倾斜率为：最大子节点数据量/平均节点数据量。
为避免整张表的数据量为空，同时对结果的影响很小，在平均节点数据量基础上加上一个很小的值，SQL 如下：SELECT tabname,max(SIZE)/(avg(SIZE)+0.001) AS max_div_avg,sum(SIZE) total_sizeFROM(SELECT gp_segment_id,oid::regclass tabname,pg_relation_size(oid) SIZEFROM gp_dist_random('pg_class')WHERE relkind='r'AND relstorage IN ('a','h')) tGROUP BY tabnameORDER BY2DESC;3. 分区表按照某字段进行分区，不影响数据在数据节点上的分布，但是，仅在单个数据节点上，对数据进行分区存储。
可以加快分区字段的查询速度。
4. 压缩表对于大AO表和分区表使用压缩，以节省存储空间并提高系统I/O，也可以在字段级别配置压缩。
应用场景：∙不需要对表进行更新和删除操作∙访问表的时候基本上是全表扫描，不需要建立索引∙不能经常对表添加字段或者修改字段类型5. 分组扩展Greenplum数据库的GROUP BY扩展可以执行某些常用的计算，且比应用程序或者存储过程效率高。
GROUP BY ROLLUP(col1, col2, col3)GROUP BY CUBE(col1, col2, col3)GROUP BY GROUPING SETS((col1, col2), (col1, col3))ROLLUP 对分组字段（或者表达式）从最详细级别到最顶级别计算聚合计数。
ROLLUP的参数是一个有序分组字段列表，它计算从右向左各个级别的聚合。
例如ROLLUP(c1, c2, c3) 会为下列分组条件计算聚集：(c1, c2, c3)(c1, c2)(c1)()CUBE 为分组字段的所有组合计算聚合。
例如CUBE(c1, c2, c3) 会计算一下聚合：(c1, c2, c3)(c1, c2)(c2, c3)(c1, c3)(c1)(c2)(c3)()GROUPING SETS 指定对那些字段计算聚合，它可以比ROLLUP和CUBE更精确地控制分区条件。
6. 窗口函数窗口函数可以实现在结果集的分组子集上的聚合或者排名函数，例如sum(population) over (partition by city)。
窗口函数功能强大，性能优异。
因为它在数据库内部进行计算，避免了数据传输。
∙窗口函数row_number()计算一行在分组子集中的行号，例如row_number() over (order by id)。
∙如果查询计划显示某个表被扫描多次，那么通过窗口函数可能可以降低扫描次数。
∙窗口函数通常可以避免使用自关联。
7. 列存储和行存储列存储亦即同一列的数据都连续保存在一个物理文件中，有更高的压缩率，适合在款表中对部分字段进行筛选的场景。
需要注意的是：若集群中节点较多，而且表的列也较多，每个节点的每一列将会至少产生一个文件，那么总体上将会产生比较多的文件，对表的DDL操作就会比较慢。
在和分区表使用时，将会产生更多文件，甚至可能超过linux的文件句柄限制，要尤其注意。
∙行存储：如果记录需要update/delete，那么只能选择非压缩的行存方式。
对于查询，如果选择的列的数量经常超过30个以上的列，那么也应该选择行存方式。
∙列存储：如果选择列的数量非常有限，并且希望通过较高的压缩比换取海量数据查询时的较好的IO性能，那么就应该选择列存模式。
其中，列存分区表，每个分区的每个列都会有一个对应的物理文件，所以要注意避免文件过多，导致可能超越linux 上允许同时打开文件数量的上限以及DDL命令的效率很差。
8. 函数和存储过程虽然支持游标但是，尽量不要使用游标方式处理数据，而是应该把数据作为一个整体进行操作。
9. 索引使用∙如果是从超大结果集合中返回非常小的结果集（不超过5%），建议使用BTREE索引（非典型数据仓库操作）∙表记录的存储顺序最好与索引一致，可以进一步减少IO（好的index cluster）∙where条件中的列用or的方式进行join，可以考虑使用索引∙键值大量重复时，比较适合使用bitmap索引有关索引使用的测试见GP索引调优测试–基本篇和GP索引调优测试–排序篇。