标签: optimization

我可以在 AdventureWorks 表 Person.Person 上创建以下约束：

ALTER TABLE Person.Person ADD CONSTRAINT ConstantScan CHECK (LastName <> N'Doesn''t Exist')

这告诉 SQL Server LastName 的值不能为Doesn't Exist

优化器在以下简单查询中利用了这一点：

SELECT  *
FROM    Person.Person
WHERE   LastName = N'Doesn''t Exist'

由于约束告诉优化器列中没有任何内容可以等于我们正在相等搜索的值（假设有可信约束），因此优化器仅执行持续扫描并且“不执行任何操作”

如果我放弃上面的约束并创建一个稍微不同的约束：

ALTER TABLE Person.Person ADD CONSTRAINT ConstantScan2 CHECK (LastName <> N'Doesn''t Exist' AND FirstName <> N'Doesn''t Exist')

并使用谓词运行查询，其结果将违反检查约束：

SELECT  *
FROM    Person.Person
WHERE   FirstName = N'Doesn''t Exist' AND
        LastName = N'Doesn''t Exist' 

我们通过键查找进行索引查找

但是，如果我跑

SELECT  *
FROM    Person.Person
WHERE   FirstName = N'Doesn''t Exist' …

给出以下两个表：

CREATE TABLE SalesLedger (
  Id int PRIMARY KEY IDENTITY,
  Date date NOT NULL,
  Total decimal(38,18),
  INDEX IX (Date, Total)
);

CREATE TABLE Purchases (
  Id int PRIMARY KEY IDENTITY,
  Date date NOT NULL,
  Total decimal(38,18),
  INDEX IX (Date, Total)
);

以及下面的视图

CREATE VIEW ViewMetrics
AS

Select
  Date,
  'Sale' as Metric,
  Total as Value
From SalesLedger

UNION ALL

Select
  Date,
  'Purchase' as Metric,
  Total as Value
From Purchases;

以下查询使用一Concatenation Sort对：

Select SUM(Value) as Sales, Date
from ViewMetrics …

我从未找到将一行的多个字段索引为索引条目或在 MySQL 上模拟此功能的好方法。

当您将字段用作标签或类似概念时，就会出现问题。例如：字段名称为 tag1、tag2、tag3。要快速搜索具有特定标签的行，您需要有 3 个索引并以最基本和最明显的方式执行 3 个单独的查询。

有没有办法将这 3 个字段索引为一个索引的条目，只允许一次搜索。

ID tag1 tag2 tag3
-- ---- ---- ----
01 abc  xyz  bla
02 foo  bar  ble
03 xyz  bla  bar

index
abc -> 01
bar -> 02 03
bla -> 01 03
ble -> 02
foo -> 02
xyz -> 01 03

或者有没有其他方法可以有效地做到这一点？

为了对现有的未分区表进行分区，可以使用 EXCHANGE PARTITION 或 DBMS_REDEFINITION。如何决定为表分区选择哪些可能性。这是否取决于表中有多少数据？一种操作比另一种更安全吗？

下面是我的 .NET 应用程序运行时的慢查询日志。请让我知道如何提高查询的性能：

TCP Port: 3306, Named Pipe: (null)
Time                 Id Command    Argument
# Time: 110805 13:25:39
# User@Host: root[root] @ localhost [127.0.0.1]
# Query_time: 0.015625  Lock_time: 0.000000 Rows_sent: 1  Rows_examined: 1373
use stockist;
SET timestamp=1312530939;
SELECT SUM(GROSSAMOUNT) FROM BILLDETAILS WHERE MONTH(BILLDATE) = 8 AND YEAR(BILLDATE) = 2011;
# User@Host: root[root] @ localhost [127.0.0.1]
# Query_time: 0.000000  Lock_time: 0.000000 Rows_sent: 1  Rows_examined: 1373
SET timestamp=1312530939;
SELECT COUNT(BILLNO) FROM BILLDETAILS WHERE MONTH(BILLDATE) = 8 AND YEAR(BILLDATE) = 2011;
# Time: 110805 …

我有一个每天晚上运行的数据库作业来创建一个仓库表。使用我的新数据库服务器和 SAN，我将过程从 4 1/2 小时缩短到 35 分钟。我已经将它优化为通过实验在最短的时间内运行（WITH INDEX NOLOCK、FORCE ORDER、LOOP JOIN、MAXDOP 0）。我对改进感到满意，但我讨厌不知道为什么查询需要这么长时间。我完全可以接受瓶颈，只要我知道它们在哪里。当此查询运行时，在很长一段时间内，明显的资源都未得到充分利用。SQL Server 在这些时候在做什么？

我负责监督使用 SQL Server 作为其后端存储解决方案的应用程序。不幸的是，该应用程序没有关于如何使用 RDBMS 的概念，似乎主要像使用 NoSQL 解决方案一样使用它。应用程序最需要的是获取和存储单个记录，并且不使用任何外键来保证数据完整性。

正如预期的那样，这种出色的设计导致了相当差的性能，因为将 RDBMS 用于仅需要磁盘散列样式方案的问题就像对蚊子使用大炮一样。但可惜的是，我无法修改该软件，因为它是第三方软件。

我已经看到许多提示，很高兴告诉我应该使用更有效的查询，但这根本不是一个选择。SQL Server 似乎主要受 CPU 限制，而且大部分数据似乎也缓存在内存中。有没有一种方法可以优化/配置 SQL 处理来自该应用程序的请求的方式？（整个 SQL Server 实例仅供应用程序使用。）或者，是否有另一种解决方案，其行为与 SQL Server 相似，但在简单查询的速度上与 NoSQL 相似？SQL Server 是否有某种单进程模式使锁定记录变得不必要？

我应该尝试一下任何离奇的想法吗？

更新： 因此，在对带有自动生成的游标准备、执行、获取等的跟踪进行大量处理之后，看起来在关注的特定应用程序功能中的大部分时间都浪费在填充表上，只有第一行实际上是获取的。这实际上似乎是应用程序编写方式的常见问题。

由于游标后面的 select 语句对数据进行排序，游标不能有效地使用动态计划。最终，应用程序试图获取的数据是下一个记录，field A = document_id并且下一个field B值大于先前寻求的field B值。当然，这是游标的典型应用——如果应用程序以典型方式使用游标的话。

我想再次联系供应商，因为这...很糟糕。我认为它们更有可能出现在一个简单的两行已经存在的修复中。因此，我希望生成一个更高效的查询版本（仍然使用游标，具有相同的客户端语义“给我下一条记录，k？”）。我不确定如何在 TSQL 中制定这样的查询，因为我给出的所有结果都会导致扫描，即使是我认为有用的索引。（真的，只需要一个 b 树搜索，但不知何故我似乎无法到达那里。）

在我的网站上，我在一个简单的 mysql 表中记录每个综合浏览量（日期、IP、引用、页面等）。

该表具有以下活动：

• SELECT每分钟1个
• DELETE每分钟1个
• 没有UPDATE查询
• 很多INSERTS（大约每秒 300 个）。

该表永远不会大于 200MB。

今天，我将这个表从 InnoDB 表更改为 MEMORY 表，这对我来说是有意义的，以防止不必要的硬盘 IO。我还每分钟修剪一次这张桌子，以确保它永远不会变得太大。而且这个信息不是很重要，所以在 MySQL 重启时删除它并不重要。

——

性能方面，一切都运行良好。但是我注意到在运行 tuning-primer 时，使用 MEMORY 表时我的当前锁定等待率非常高。

Current Lock Wait ratio = 1 : 561

如果我将此表更改为 InnoDB，则比率为：

Current Lock Wait ratio = 0 : 78600946

我的问题：我应该担心这个锁定等待率吗？有什么我可以改变我的配置来改进的东西，以便使用 MEMORY 表的锁定等待率不会那么高？

有谁知道 MS SQL Server 文本查询是否针对大写或小写字符串进行了优化？

我在某处读到它是大写的，但似乎无法再次找到对它的引用。当然，如果这是完全错误的并且没有进行优化，那么知道这也很有用。

谢谢你的帮助。

厘米

作为 MySQL DBA，大多数时候我们应该优化性能不佳的 MySQL 服务器。

现在我的问题是从哪里开始，就像我们需要找出很多事情一样

1.Find the duplicate indexes.
2.Find unused indexes on the basis of selectivity.
3.Monitor the Server Parameters(What should be important parameters).
4.Execute MySQL Server performance tuning script.
5.Slow logs

那么检查服务器的顺序应该是什么，应该监视/分析的确切内容应该是什么，以提高性能。