标签: performance

我有一个一定很常见的查询模式，但我不知道如何为它编写有效的查询。我想查找与“最近日期不晚于”另一个表的行相对应的表的行。

inventory比如说，我有一张表格，它代表了我在某一天持有的库存。

date       | good | quantity
------------------------------
2013-08-09 | egg  | 5
2013-08-09 | pear | 7
2013-08-02 | egg  | 1
2013-08-02 | pear | 2

和一张表，“价格”说，它保存了某一天的商品价格

date       | good | price
--------------------------
2013-08-07 | egg  | 120
2013-08-06 | pear | 200
2013-08-01 | egg  | 110
2013-07-30 | pear | 220

如何有效地获得库存表每一行的“最新”价格，即

date       | pricing date | good | quantity | price
----------------------------------------------------
2013-08-09 | 2013-08-07   | egg  | 5        | 120
2013-08-09 …

我有一个存储 MD5 哈希的索引列。因此，该列将始终存储 32 个字符的值。无论出于何种原因，它都是作为 varchar 而不是 char 创建的。迁移数据库以将其转换为字符是否值得？这是在带有 InnoDB 的 MySQL 5.0 中。

查看运行缓慢的查询的执行计划，我注意到有些节点是索引查找，有些是索引扫描。

索引查找和索引扫描有什么区别？

哪个表现更好？

SQL 如何选择一个？

我意识到这是 3 个问题，但我认为回答第一个会解释其他问题。

在最新版本的 PostgreSQL 中（截至 2013 年 12 月），我们能否在两个或多个内核之间共享查询以提高性能？还是我们应该获得更快的内核？

H2 是一个单线程数据库，在性能方面享有盛誉。其他数据库是多线程的。

我的问题是：多线程数据库什么时候变得比单线程数据库更有趣？有多少用户？多少个进程？什么是触发器？有人有经验可以分享吗？

概括

• 通常的瓶颈是磁盘访问
• SSD 速度很快，但很脆弱（必须执行故障程序）
• 单线程系统上的一个长查询将阻塞所有其他查询
• 配置多线程系统可能很棘手
• 即使在单核系统上，多线程数据库也是有益的

我转身innodb_flush_log_at_trx_commit = 2获得了非常快的写入速度。但是在生产网站中使用它安全吗？

我是 Oracle 数据库的新手。如果我理解正确的话，物化视图是将结果集保存为数据库中的物理表的视图，并且该视图/表根据某个参数进行刷新。如果视图保存为物理表，为什么不首先将数据存储到表中？那么使用物化视图代替表有什么好处呢？

我需要计算一个日期范围内的滚动总和。为了说明，使用AdventureWorks 示例数据库，以下假设语法将完全满足我的需要：

SELECT
    TH.ProductID,
    TH.TransactionDate,
    TH.ActualCost,
    RollingSum45 = SUM(TH.ActualCost) OVER (
        PARTITION BY TH.ProductID
        ORDER BY TH.TransactionDate
        RANGE BETWEEN 
            INTERVAL 45 DAY PRECEDING
            AND CURRENT ROW)
FROM Production.TransactionHistory AS TH
ORDER BY
    TH.ProductID,
    TH.TransactionDate,
    TH.ReferenceOrderID;

遗憾的是，RANGE窗口框架范围目前在 SQL Server 中不允许间隔。

我知道我可以使用子查询和常规（非窗口）聚合编写解决方案：

SELECT 
    TH.ProductID,
    TH.TransactionDate,
    TH.ActualCost,
    RollingSum45 =
    (
        SELECT SUM(TH2.ActualCost)
        FROM Production.TransactionHistory AS TH2
        WHERE
            TH2.ProductID = TH.ProductID
            AND TH2.TransactionDate <= TH.TransactionDate
            AND TH2.TransactionDate >= DATEADD(DAY, -45, TH.TransactionDate)
    )
FROM Production.TransactionHistory AS TH
ORDER BY
    TH.ProductID,
    TH.TransactionDate, …

我在 PostgreSQL 9.2 上有一个数据库，它有一个包含大约 70 个表的主模式和可变数量的相同结构的每个客户端模式，每个模式有 30 个表。客户端模式具有引用主模式的外键，而不是相反。

我刚刚开始用一些从以前版本中获取的真实数据填充数据库。当我不得不在主模式的一个非常中心的表中进行批量删除时，数据库已经达到大约 1.5 GB（预计在几周内会增长到几十 GB）。所有相关的外键都标记为 ON DELETE CASCADE。

这将需要很长时间，这并不奇怪，但 12 小时后很明显，我最好重新开始，删除数据库并再次启动迁移。但是，如果我稍后需要在数据库处于活动状态且更大时重复此操作怎么办？有没有替代的、更快的方法？

如果我编写一个脚本来浏览依赖表，从离中心表最远的表开始，逐表删除依赖行，会快得多吗？

一个重要的细节是某些表上有触发器。

在 MySQL 中 varchar 大小之间是否存在性能差异？例如，varchar(25)和varchar(64000)。如果没有，是否有理由不声明所有具有最大大小的 varchars 以确保您不会用完空间？