标签: performance

根据PostgreSQL 的文档，VARCHAR,VARCHAR(n)和之间没有性能差异TEXT。

我应该为名称或地址列添加任意长度限制吗？

编辑：不是欺骗：

• 当所有值都是 36 个字符时，使用 char 和 varchar 进行索引查找会明显更快吗

我知道这种CHAR类型是过去的遗物，我不仅对性能感兴趣，而且对其他优缺点感兴趣，例如 Erwin 在他惊人的回答中所述。

此查询获取您关注的人创建的帖子列表。您可以关注无限数量的人，但大多数人关注 < 1000 人。

使用这种查询方式，明显的优化是缓存"Post"id，但不幸的是我现在没有时间这样做。

EXPLAIN ANALYZE SELECT
    "Post"."id",
    "Post"."actionId",
    "Post"."commentCount",
    ...
FROM
    "Posts" AS "Post"
INNER JOIN "Users" AS "user" ON "Post"."userId" = "user"."id"
LEFT OUTER JOIN "ActivityLogs" AS "activityLog" ON "Post"."activityLogId" = "activityLog"."id"
LEFT OUTER JOIN "WeightLogs" AS "weightLog" ON "Post"."weightLogId" = "weightLog"."id"
LEFT OUTER JOIN "Workouts" AS "workout" ON "Post"."workoutId" = "workout"."id"
LEFT OUTER JOIN "WorkoutLogs" AS "workoutLog" ON "Post"."workoutLogId" = "workoutLog"."id"
LEFT OUTER JOIN "Workouts" AS "workoutLog.workout" ON "workoutLog"."workoutId" = "workoutLog.workout"."id"
WHERE
"Post"."userId" IN …

在比较两个不同查询的执行时间时，清除缓存以确保第一个查询的执行不会改变第二个查询的性能非常重要。

在 Google 搜索中，我可以找到以下命令：

DBCC FREESYSTEMCACHE
DBCC FREESESSIONCACHE
DBCC FREEPROCCACHE

事实上，在多次执行后，我的查询需要比以前更现实的时间来完成。但是，我不确定这是推荐的技术。

最佳做法是什么？

我一直在阅读 Kimberly Tripp 撰写的一些关于 SQL Server 计划缓存的精彩文章，例如：http : //www.sqlskills.com/blogs/kimberly/plan-cache-and-optimizing-for-adhoc-workloads/

为什么甚至有“针对临时工作负载进行优化”的选项？这不应该一直开着吗？无论开发人员是否使用 ad-hoc SQL，为什么不在每个支持它的实例上启用此选项（SQL 2008+），从而减少缓存膨胀？

我继承了执行以下操作的维护计划：

• 清理旧数据
• 检查数据库完整性
• 执行数据库和事务日志备份
• 重组我们的索引
• 更新统计
• 删除旧备份和维护计划文件

在 23 分钟的维护计划中，更新统计数据需要惊人的 13 分钟。在这 13 分钟期间，对数据库的访问被阻止（或者至少，从这个数据库到我们其他数据库的复制被暂停）。

我的问题是：

我们应该什么时候更新统计数据，为什么？

这似乎是我们应该比每天少做的事情。我试图让我们摆脱“仅仅因为”进行不必要维护的心态。

在 Ubuntu 12.04 上使用 PG 9.1。

目前，我们在数据库上运行大量 UPDATE 语句最多需要 24 小时，它们的形式如下：

UPDATE table
SET field1 = constant1, field2 = constant2, ...
WHERE id = constid

（我们只是覆盖由 ID 标识的对象的字段。）这些值来自外部数据源（尚未在数据库中的表中）。

每个表都有几个索引，没有外键约束。直到最后都没有提交。

导入pg_dump整个数据库的一个需要 2 小时。这似乎是我们应该合理定位的基线。

除了生成以某种方式重建数据集以供 PostgreSQL 重新导入的自定义程序之外，我们是否可以做些什么来使批量 UPDATE 性能更接近导入的性能？（这是一个我们认为日志结构合并树处理得很好的领域，但我们想知道是否可以在 PostgreSQL 中做任何事情。）

一些想法：

• 删除所有非 ID 索引然后重建？
• 增加 checkpoint_segments，但这真的有助于维持长期吞吐量吗？
• 使用这里提到的技术？（将新数据加载为表，然后“合并”在新数据中找不到 ID 的旧数据）

基本上有很多事情要尝试，但我们不确定什么是最有效的，或者我们是否忽略了其他事情。我们将在接下来的几天里进行实验，但我们想我们也会在这里问。

我确实在表上有并发负载，但它是只读的。

我们的系统写入了大量数据（一种大数据系统）。写入性能足以满足我们的需求，但读取性能真的太慢了​​。

我们所有表的主键（约束）结构都相似：

timestamp(Timestamp) ; index(smallint) ; key(integer).

一个表可以有数百万行，甚至数十亿行，而一个读请求通常是针对特定时间段（时间戳/索引）和标记的。查询返回大约 20 万行是很常见的。目前，我们每秒可以读取大约 15k 行，但我们需要快 10 倍。这是可能的，如果是，如何？

注意： PostgreSQL 是和我们的软件一起打包的，所以不同客户端的硬件是不一样的。

它是一个用于测试的虚拟机。VM 的主机是具有 24.0 GB RAM 的 Windows Server 2008 R2 x64。

服务器规范（虚拟机 VMWare）

Server 2008 R2 x64
2.00 GB of memory
Intel Xeon W3520 @ 2.67GHz (2 cores)

postgresql.conf 优化

shared_buffers = 512MB (default: 32MB)
effective_cache_size = 1024MB (default: 128MB)
checkpoint_segment = 32 (default: 3)
checkpoint_completion_target = 0.9 (default: 0.5)
default_statistics_target = 1000 (default: 100)
work_mem = 100MB (default: 1MB)
maintainance_work_mem = 256MB …

我正在尝试优化一个查询，该查询查看一个大表（3700 万行），并有一个关于在查询中执行操作的顺序的问题。

select 1 
from workdays day
where day.date_day >= '2014-10-01' 
    and day.date_day <= '2015-09-30' 
    and day.offer_id in (
        select offer.offer_day 
        from offer  
        inner join province on offer.id_province = province.id_province  
        inner join center cr on cr.id_cr = province.id_cr 
        where upper(offer.code_status) <> 'A' 
            and province.id_region in ('10' ,'15' ,'21' ,'26' ,'31' , ...,'557') 
            and province.id_cr in ('9' ,'14' ,'20' ,'25' ,'30' ,'35' ,'37')
    )

WHERE日期范围的子句是否在子查询之前执行？将最严格的子句放在首位以避免其他子句的大循环，以便更快地执行是否是一种好方法？

现在查询需要很多时间来执行。

大多数表使用 MySQL 5.6 和 InnoDB 存储引擎。InnoDB 缓冲池大小为 15 GB，Innodb DB + 索引大约为 10 GB。服务器有 32GB RAM 并运行 Cent OS 7 x64。

我有一张包含大约 1000 万条记录的大表。

我每 24 小时从远程服务器获取更新的转储文件。该文件为 csv 格式。我无法控制那种格式。该文件约为 750 MB。我尝试将数据逐行插入 MyISAM 表，花了 35 分钟。

我只需要从文件中的每行 10-12 中取出 3 个值并在数据库中更新它。

实现这样的目标的最佳方法是什么？

我需要每天都这样做。

目前 Flow 是这样的：

1. mysqli_begin_transaction
2. 逐行读取转储文件
3. 逐行更新每条记录。
4. mysqli_commit

以上操作大约需要30-40 分钟才能完成，在执行此操作时，还有其他更新正在进行中，这给了我

超过锁等待超时；尝试重新启动事务

更新 1

使用LOAD DATA LOCAL INFILE. 在 MyISAM 中，38.93 sec在 InnoDB 中需要 7 分 5.21 秒。然后我做了：

UPDATE table1 t1, table2 t2
SET …

我试图让 PostgreSQL 积极地自动清空我的数据库。我目前已按如下方式配置自动真空吸尘器：

• autovacuum_vacuum_cost_delay = 0 #关闭基于成本的真空
• autovacuum_vacuum_cost_limit = 10000 #最大值
• autovacuum_vacuum_threshold = 50 #默认值
• autovacuum_vacuum_scale_factor = 0.2 #默认值

我注意到自动真空仅在数据库未加载时才会启动，因此我遇到死元组比活元组多得多的情况。有关示例，请参阅随附的屏幕截图。其中一张表有 23 个活动元组，但有 16845 个死元组等待真空。这太疯狂了！

当测试运行完成并且数据库服务器空闲时，自动真空开始，这不是我想要的，因为我希望自动真空在死元组数量超过 20% 活元组 + 50 时启动，因为数据库已经配置。服务器空闲时的自动真空对我来说是无用的，因为生产服务器预计会在持续时间内达到 1000 次更新/秒，这就是为什么即使服务器负载不足我也需要自动真空运行。

有什么我想念的吗？如何在服务器负载较重时强制运行自动吸尘器？

更新

这可能是一个锁定问题吗？有问题的表是通过插入后触发器填充的汇总表。这些表以 SHARE ROW EXCLUSIVE 模式锁定，以防止并发写入同一行。