标签: optimization

我目前正在开发一个项目，该项目从平面文件 (csv) 中批量导入数据，大约 18 个不同的文件通过一些存储过程链接到特定的表。

我按照数据加载性能指南中的建议进行了操作。

数据库处于BulkLogged恢复模式以最小化日志记录，当在包含 600000 行的文件上执行以下存储过程时，我收到错误

消息 9002，级别 17，状态 4，过程 SP_Import__DeclarationClearanceHistory_FromCSV，第 34 行
数据库的事务日志已满。要找出无法重用日志中的空间的原因，请参阅 sys.databases 中的 log_reuse_wait_desc 列

（出于测试目的，我在开始导入之前进行了完整备份）。

看着log_reuse_wait_desc我看到以下内容：

log_reuse_wait_desc 检查点。所有其他导入成功导入。

欢迎任何解决此问题的意见。

PROCEDURE [dbo].[SP_Import_DeclarationClearanceHistory_FromCSV]
    @FilePath [nvarchar](1000)
AS
BEGIN
    -- Creating a Temproary Table for importing the data from csv file.
    DBCC TRACEON(610)

    CREATE TABLE #DeclarationClearanceHistory
    (
          [ItemID] [int] IDENTITY(1, 1) NOT NULL ,
          [CMSDeclarationID] [bigint] NOT NULL ,
          [StatusCode] [nvarchar](10) NOT NULL ,
          [SubStatus] [nvarchar](10) NULL ,
          [DepartmentCode] [nvarchar](10) …

就像 SQL Server 中的 MEMO 结构一样，它是优化器在优化查询时所采取的步骤的“书面记录”。MySQL 中是否有任何内容可以让我获得诸如优化器考虑的计划、每个计划的成本之类的信息？

我需要对数据库结构做出决定，决定是将一对一关系列分成多个表并与一个关系 id 链接，还是只是将所有列添加到一个表中。

列数约为 45，我需要对不同查询的不同列上的数据进行排序（每个查询一种排序）。

我将使用 MyISAM 存储引擎。

此外，表中将有数百万条数据。

我构建了以下 SQL Server 查询，但它遇到了SQL Server 2005 中的反半连接缺陷，导致基数估计不准确（1 - 呃！）并永远运行。由于它是一个长期的生产 SQL Server，我不能轻易建议升级版本，因此我不能在这个特定查询上强制使用 traceflag 4199 提示。

我很难重构WHERE AND NOT IN (SELECT). 有人可以帮忙吗？我确保尝试使用基于集群密钥对的最佳连接。

SELECT TOP 5000 d.doc2_id
    ,d.direction_cd
    ,a.address_type_cd
    ,d.external_identification
    ,s.hash_value
    ,d.publishdate
    ,d.sender_address_id AS [D2 Sender_Address_id]
    ,a.address_id AS [A Address_ID]
    ,d.message_size
    ,d.subject
    ,emi.employee_id
FROM assentor.emcsdbuser.doc2 d(NOLOCK)
INNER JOIN assentor.emcsdbuser.employee_msg_index emi(NOLOCK)
    ON d.processdate = emi.processdate
    AND d.doc2_id = emi.doc2_id
INNER LOOP JOIN assentor.emcsdbuser.doc2_address a(NOLOCK)
    ON emi.doc2_id = a.doc2_id
    AND emi.address_type_cd = a.address_type_cd
    AND emi.address_id = a.address_id
INNER JOIN sis.dbo.sis s(NOLOCK) …

为什么NOT IN执行INDEX SCAN而不是INDEX SEEK？

这是我目前在桌子上的索引，

CREATE NONCLUSTERED INDEX [idx_dmcasarms_CourseList_cDesc] 
ON [dbo].[courselist]
(
    [c_desc] ASC,
    [c_code] ASC
)

SQL语句，

SELECT  c_code CourseCode
FROM    courselist
WHERE   c_desc = 'BACHELOR OF SCIENCE IN INFORMATION TECHNOLOGY'
GO

SELECT  c_code CourseCode
FROM    courselist
WHERE   c_desc NOT IN ('PRE SCHOOL', 'BASIC EDUCATION', 'SCIENCE HIGH SCHOOL')
GO

和执行计划，

无论如何我可以优化这个吗？

幸运的是，当我尝试在大长度文本列上创建唯一索引时，Erwin Brandstetter救了我。

插入率的上限是每年数百亿行。

对于我的实现，散列永远不需要离开数据库，但散列数据必须经常与外部数据进行比较才能存在。

根据我针对这些目的进行优化的有限经验，我假设散列的最佳数据类型是bytea. 替代方案当然是更长的十六进制字符串。

bytea这些哈希的最佳数据类型是否正确？

如果bytea不是最优的，什么是最优的？

我的意图应该如何实现？

澄清

我根据 Erwin Brandstetter 的建议使用文本的哈希值，以确保大文本是唯一的。我有限的理解是，原始二进制数据总是性能最好的，尤其是与字符串相比时。

只需比较哈希是否存在即可抢占唯一性违规，因此哈希很高兴永远不需要离开数据库。由于 libpqxx 令人难以置信的设计，看起来好像数据可以简单地通过准备好的语句输入并使用(decode(md5($1::text), 'hex')). 当我更熟悉bytea通过 libpqxx 3.1 插入时，我会将其移至 C++。

对于此实现，冲突是可以接受的，因为可以在不破坏系统的情况下重建数据以符合要求。

如果愉快地达到最大吞吐量，那么应该预期经济资源将可用于容纳它；因此，主要关注点始终是性能，所以如果我对 Postgres 的功能及其分区表处理这些行数的能力的理解是准确的，那么它有望在很长一段时间内成为该工作的正确工具。幸运的是，超过几秒钟的数据永远不会改变，我的理解是 Postgres 分区表可以将这些数据制成碎肉。如果没有，这将是那些好问题之一。

我有一个使用 sqlite3 作为数据库的小网络应用程序（数据库相当小）。

现在，我正在使用以下查询生成一些要显示的内容：

SELECT dbId,
        dlState,
        retreivalTime,
        seriesName,
        <snip irrelevant columns>
        FROM DataItems
        GROUP BY seriesName
        ORDER BY retreivalTime DESC
        LIMIT ?
        OFFSET ?;

其中limit通常为 ~200，并且offset为 0（它们驱动分页机制）。

无论如何，现在，这个查询完全扼杀了我的表现。在具有约 67K 行的表上执行大约需要 800 毫秒。

我在seriesName和上都有索引retreivalTime。

sqlite> SELECT name FROM sqlite_master WHERE type='index' ORDER BY name;
<snip irrelevant indexes>
DataItems_seriesName_index
DataItems_time_index           // This is the index on retreivalTime. Yeah, it's poorly named

但是，EXPLAIN QUERY PLAN似乎表明它们没有被使用：

sqlite> EXPLAIN QUERY PLAN SELECT dbId, 
                                  dlState, …

我正在使用一个表，该表的所有字符类型都设置为nvarchar其中一些是nvarchar(max). 我们正在将所有这些转换为varchar并根据生产中的实际使用指定字符宽度。对于任何给定的列，生产数据使用 2 个字符到 900 个字符的实际使用宽度范围。我们将在适用时添加 10% 的填充。

-- Insert statements for procedure here
UPDATE Listings WITH (ROWLOCK) 
SET [SubType] = 'S' 
WHERE @idSettings = idSettings AND
    (@idRetsClass = 0 OR idRetsClass = @idRetsClass)
    AND (@idRetsSetting = 0 OR idRetsSetting = @idRetsSetting)
    AND IsNew = 1 AND ([SubType] LIKE '%Single Family Home%' OR [SubType] LIKE '%Modular%' OR [SubType] LIKE '%Mobile Home%' 
    OR [SubType] LIKE '% Story%' OR [SubType] = '' OR [SubType] = 'residential …

SELECT A
FROM T
WHERE M > 1000 AND M < 5000;

我无法判断以下哪个最适合上述查询：

1. 线性搜索
2. M 上的二分查找
3. 在 M 上有索引的 B+-树
4. 在 A 上有索引的 B+-tree

哪个是最佳答案，为什么？

我最近在考试中遇到了这个问题，但找不到解决方案。我选择了选项 3（在 M 上有索引的 B+ 树），因为查询不是在 M 上排序的，并且与 M 相比，A 上的 B+ 树索引会使其变得困难（我猜）。

我想对这些概念进行一些澄清，因为我对何时可以有效地使用上述每个概念感到有些困惑。

更清楚一点：当查询优化器选择优化计划时，它会选择哪个给定选项？这就是问题的意图。

我对数据库管理还是个新手，我正在尝试优化搜索查询。

我有一个看起来像这样的查询，在某些情况下需要 5-15 秒来执行，并且还导致 100% 的 CPU 使用率：

DECLARE @point geography;
SET @point = geography::STPointFromText('POINT(3.3109015 6.648294)', 4326); 

SELECT TOP (1)
     [Result].[PointId] AS [PointId], 
     [Result].[PointName] AS [PointName], 
     [Result].[LegendTypeId] AS [LegendTypeId], 
     [Result].[GeoPoint] AS [GeoPoint]
FROM ( 
    SELECT 
        [Extent1].[GeoPoint].STDistance(@point) AS distance, 
        [Extent1].[PointId] AS [PointId], 
        [Extent1].[PointName] AS [PointName], 
        [Extent1].[LegendTypeId] AS [LegendTypeId], 
        [Extent1].[GeoPoint] AS [GeoPoint]
    FROM [dbo].[GeographyPoint] AS [Extent1]
    WHERE 18 = [Extent1].[LegendTypeId] 
)  AS [Result]
ORDER By [Result].distance ASC

该表在 PK 上有一个聚集索引，在geography类型列上有一个空间索引。

所以当我执行上述查询时，它正在执行扫描操作。

所以我在LegendTypeId列上创建了一个非聚集索引：

CREATE NONCLUSTERED INDEX [GeographyPoint_LegendType_NonClustered] ON [dbo].[GeographyPoint] …