我有一个 PostgreSQL 9.3 表，其中包含一些数字和一些附加数据：
CREATE TABLE mytable (
myid BIGINT,
somedata BYTEA
)
该表目前有大约 10M 条记录，占用 1GB 磁盘空间。myid不连续。
我想计算 100000 个连续数字的每个块中有多少行：
SELECT myid/100000 AS block, count(*) AS total FROM mytable GROUP BY myid/100000;
这将返回大约 3500 行。
我注意到某个索引的存在显着加快了这个查询，即使查询计划根本没有提到它。没有索引的查询计划：
db=> EXPLAIN (ANALYZE TRUE, VERBOSE TRUE) SELECT myid/100000 AS block, count(*) AS total FROM mytable GROUP BY myid/100000;
QUERY PLAN
----------------------------------------------------------------------------------------------------------------------------------------
GroupAggregate (cost=1636639.92..1709958.65 rows=496942 width=8) (actual time=6783.763..8888.841 rows=3460 loops=1)
Output: ((myid / 100000)), count(*)
-> Sort (cost=1636639.92..1659008.91 rows=8947594 width=8) (actual time=6783.752..8005.831 …我正在寻找有关如何为开发团队使用的数据库设置事务日志的建议。这些数据库是短暂的，因为我们从不关心硬件/软件故障时的数据恢复。相反，每次开发人员开始一项任务时，他们都会创建一个新数据库并从头开始填充数据，因此他们也会在硬件出现故障时这样做。另一个用例是自动化测试，其中为每次测试运行创建一个新数据库。
目前，由于开发人员的使用模式（测试不同类型的查询，频繁的数据批量加载），日志增长了很多，而且更多的是障碍而不是帮助。我们已经看到这样的情况：在开发人员的工作仅一个小时后，日志就开始占用 0.5 TB，迫使他们手动截断日志。由于我们不想在自动化测试期间手动截断日志，我们需要为它们分配更大的机器。我怀疑需要更多 I/O，从而减慢操作速度。
我可以在 SQL Server 文档和其他材料中找到的任何建议都适用于生产服务器并专注于数据恢复，这与我正在寻找的完全相反。
当数据恢复无关紧要，而不是操作的难易性、资源使用和原始速度更受关注时，有关配置 SQL Server 的事务日志的一些好的做法是什么？
这是Queries 随机变慢的后续行动，良好的预防措施？，试图就那里陈述的一个想法提出更具体的问题。
查询在长时间的快速历史之后突然变慢的一个常见原因是基数估计过时。SQL Server 利用基数估计来找出最快回答给定查询的查询计划。如果由于基数估计过时，通常需要几分钟的查询突然激增至数十小时，则可能会在支持人员做出响应之前对业务使用产生负面影响。
是否有任何措施可以在执行查询之前先发制人地应用以查找和修复过时的基数估计？是否有任何特定的工具可以定期执行以检查并修复它们，或者可能需要观察一些指标来表明数据库中的估计值有多好？
我们支持基于 SQL Server 的内部应用程序的多种部署。
我们现在遇到过几次问题，一些曾经快速而小的查询突然变得非常缓慢或不稳定，而不一定会产生更多的数据或在更大的数据集上运行。
每次发生这种情况时，都是突然开始缓慢运行的不同查询。每当这种情况发生时，我们必须花一些开发时间来调试问题，可能会再次编写查询并与以前的版本进行基准测试等等。 然而，原始查询通常可以正常工作多年，而且我们事先没有迹象表明它的执行时间可能会爆炸。
有哪些好的做法可以防止查询随机变慢？
我所追求的不是“如何修复我们已经观察到很慢的查询”，而是首先如何降低查询变慢的可能性——一种主动的方法，而不是被动的。我需要一种方法来强制 SQL Server 不要尝试过多地优化查询：我真的不需要快速，我需要一致。如果有一些选择让 SQL Server 在构建查询计划时更加保守，而不是试图利用数据分布等，我会追求它们。