我正在优化我们的数据库。本质上，我试图在我们的数据库中找到写入次数最多和读取次数最多的表。之后，我将把这些表符号链接到单独的驱动器中。

有没有办法跟踪每个表的活动？如下所示，每个表的 IOPS、写入、读取？

查询 1：

select distinct email from mybigtable where account_id=345

需要 0.1 秒

查询 2：

Select count(*) as total from mybigtable where account_id=123 and email IN (<include all from above result>)

需要 0.2 秒

查询 3：

Select count(*) as total from mybigtable where account_id=123 and email IN (select distinct email from mybigtable where account_id=345)

需要 22 分钟，其中 90% 处于“准备”状态。为什么要花这么多时间。

表是 innodb，在 MySQL 5.0 上有 320 万行

我的数据库速度变慢了。phpMyAdmin 中的分析器建议我OPTIMIZE TABLE在我的表上运行。

但在这样做之前，我（当然）想知道表中的数据是否会发生任何事情，或者此操作是否完全无害。

使用时我应该考虑利弊OPTIMIZE TABLE吗？索引和主键会保持不变吗？数据库中是否有优化后会变慢的区域？

我们知道，在优化过程中，备忘录结构被修剪，一些昂贵的替代计划被丢弃。我想知道是否有任何方法可以防止这种情况发生，让优化器只考虑每个可能的计划并从所有备选方案中选择最佳方案？

我想提出一些维护我们的 MySQL 数据库、版本 5.5/6 和使用 InnoDB 的最佳实践。

我遇到了这篇文章，它基本上是在说优化表：

1. 如果您的查询不使用 PK，则不会有太大的改进。
2. 表上的其他索引以伪随机顺序构建，很可能不会从优化表中受益。
3. 实际上可能会使更新变慢，因为现在每个更改都有更高的概率导致页面拆分。

我的问题是：

1. 以上 3 点总是正确的吗？部分？一点也不？
2. 什么时候可以尝试优化表格？
3. 在哪些情况下优化表不会受益，甚至会使表的某些用途变得更糟？
4. 除了PK之外，有没有办法优化表的索引？

环境

在数据仓库中，我将一个事实表连接到 20 个维度。事实表有 3200 万行和 30 列。这是一个临时登台表，因此我不必处理其他用户读取或写入该表。我从基表中选择 10 列，从相应维度中选择 20 列。维度表很小（在 3 到 15.000 行之间）。连接的字段是整数和 nvarchars。我使用 SELECT ... INTO 语句。表上没有索引。

此查询的执行速度太慢而无用。

试用的解决方案

由于查询处理时间太长，我尝试了以下解决方案：

1. 将 20 个连接拆分为 5 个表上的 4 个连接。但是查询性能仍然很低。
2. 将索引放在外键列上。时间没有明显减少。
3. 确保连接条件的字段是整数。我注意到性能提高了 25%。不完全是我正在寻找的。
4. 使用 insert into 语句而不是 select into。尽管数据库处于简单恢复模式，但由于日志文件增长而导致性能下降。

这些发现使我将实际执行计划包括在内，该计划表明 89% 的成本在于表插入。其他成本是 8% 的事实表表扫描和 2% 的内连接哈希匹配。

问题

1. 表插入慢的可能原因是什么？
2. 在没有执行计划的情况下，有什么方法可以识别这个瓶颈？
3. 我可以采取哪些措施来降低表插入的成本？

我正在通过 Heroku 使用 Postgres 9.3。

我有一个表，“交通”，有 100 万条记录，每天都有很多插入和更新。我需要在不同的时间范围内跨该表执行 SUM 运算，这些调用最多可能需要 40 秒，我很想听听有关如何改进它的建议。

我在这张桌子上有以下索引：

CREATE INDEX idx_traffic_partner_only ON traffic (dt_created) WHERE campaign_id IS NULL AND uuid_self <> uuid_partner;

这是一个示例 SELECT 语句：

SELECT SUM("clicks") AS clicks, SUM("impressions") AS impressions
FROM "traffic"
WHERE "uuid_self" != "uuid_partner"
AND "campaign_id" is NULL
AND "dt_created" >= 'Sun, 29 Mar 2015 00:00:00 +0000'
AND "dt_created" <= 'Mon, 27 Apr 2015 23:59:59 +0000' 

这是解释分析：

Aggregate  (cost=21625.91..21625.92 rows=1 width=16) (actual time=41804.754..41804.754 rows=1 loops=1)
  ->  Index Scan using idx_traffic_partner_only on …

编辑：为什么会话报告被阻止但等待PAGELATCH_*，而不是LCK_M_相关的等待类型？

我之前假设 SQL Server 只会在 blocks_session_Id 列中报告阻塞会话。如果被阻塞的会话正在等待逻辑锁而不是其他任何东西，例如PAGELATCH_*.

Microsoft 是否更改了有关文件数量和并行度的查询优化器？优化器是否不再考虑文件数量来确定查询的并行度？如果是这样，有人知道更改是什么时候进行的吗？如果没有，任何人都可以提供指向讨论该主题的 Microsoft 文档的链接（SQL Server 2014 或 2016 的当前文档）？

我正在尝试调整在 20 列上调用相同表值函数 (TVF) 的查询。

我做的第一件事是将标量函数转换为内联表值函数。

是否使用性能CROSS APPLY最佳的方式在查询中的多个列上执行相同的函数？

一个简单的例子：

SELECT   Col1 = A.val
        ,Col2 = B.val
        ,Col3 = C.val
        --do the same for other 17 columns
        ,Col21
        ,Col22
        ,Col23
FROM t
CROSS APPLY
    dbo.function1(Col1) A
CROSS APPLY
    dbo.function1(Col2) B
CROSS APPLY
    dbo.function1(Col3) C
--do the same for other 17 columns

有更好的选择吗？

可以在针对 X 个列的多个查询中调用相同的函数。

这是函数：

CREATE FUNCTION dbo.ConvertAmountVerified_TVF
(
    @amt VARCHAR(60)
)
RETURNS TABLE
WITH SCHEMABINDING
AS
RETURN
(
    WITH cteLastChar
    AS(
        SELECT LastChar = RIGHT(RTRIM(@amt), 1)
    ) …