相关疑难解决方法(0)

每当我在 SQL Server Management Studio 2008（数据库是 SQL Server 2005）的表中手动插入一行时，我的新行就会出现在列表的顶部而不是底部。我正在使用身份列，这会导致诸如

id  row
42 first row
1 second row
2 third row

当获取行且未明确排序时。当为 Web 应用提取行并更改TOP 1查询返回的内容时，这会导致不同的外观。

我知道我可以order by，但为什么会发生这种情况？我的大部分数据都是通过 Web 应用程序插入的，从该应用程序插入的所有数据都按照先进先出的顺序进行，例如，最新的插入位于底部，因此 ID 都在一行中。服务器或 Management Studio 中是否有某些设置会导致这种不正确的排序？

这是主键中指定的排序顺序的衍生问题，但排序是在 SELECT 上执行的。

@Catcall关于存储顺序（聚集索引）和输出顺序的主题

很多人认为聚集索引可以保证输出的排序顺序。但这不是它的作用。它保证了磁盘上的存储顺序。 例如，请参阅此博客文章。

我已经阅读了 Hugo Kornelis 的博客文章，并了解到索引并不能保证 sql server 以特定顺序读取记录。然而，我很难接受我不能为我的场景假设这一点？

CREATE TABLE [dbo].[SensorValues](
  [DeviceId] [int] NOT NULL,
  [SensorId] [int] NOT NULL,
  [SensorValue] [int] NOT NULL,
  [Date] [int] NOT NULL,
CONSTRAINT [PK_SensorValues] PRIMARY KEY CLUSTERED 
(
  [DeviceId] ASC,
  [SensorId] ASC,
  [Date] DESC
) WITH (
    FILLFACTOR=75,
    DATA_COMPRESSION = PAGE,
    PAD_INDEX = OFF,
    STATISTICS_NORECOMPUTE = OFF,
    SORT_IN_TEMPDB = OFF,
    IGNORE_DUP_KEY = OFF,
    ONLINE = OFF,
    ALLOW_ROW_LOCKS = ON,
    ALLOW_PAGE_LOCKS = ON)
  ON …

我们需要向priority表中添加一列，该列每秒被命中约 250 次，大约 170 次选择、125 次插入和 60 次更新。该列将是一个简单的number(1).

在priority无关紧要的插入或更新，即不是主键，我将单独执行的一部分。

我们基本上不想order by每秒进行 170 次超范围扫描，因为执行的数量会大幅下降。

是否索引组织表保证这priority = 1将始终来之前priority = 9运行下面的查询时：

select *
  from my_table
 where rownum < 2

对于稍微更多的上下文，典型的查询将是：

select *
  from my_table
 where mod(to_number(to_char(tstamp,'ss')),1) = 0
   and done is null
   and country = 'gbr'
   and rownum < 2

对于 IOT 的 pk 约束将成为priority, rest of the pk单独的 pk 约束，仅用于结构。done在表的大约 99% 中为空，所以这无论如何都不是很有选择性。 …

今天，在我们的 sql server 上的一个驱动器空间不足之后。该驱动器包含事件跟踪器日志，所以我认为这没什么大不了的，但后来我注意到当我将一条记录插入到数据库中时，它会将它插入到以前的记录之上而不是附加它。

当我做select *的时候，插入的记录首先出现。我能做些什么来解决这个问题吗？

section_d   section
-------------------
15          SDSD
16          SDSD2
17          SDSD2
18          adf

(4 row(s) affected)

insert into test2 values ('inserted row')

section_d   section
-----------------------
19          inserted row
15          SDSD
16          SDSD2
17          SDSD2
18          adf

(5 row(s) affected)

SQL 标准及其主流数据库实现（SQL Server、Oracle、DB2、PostgreSQL、Firebird、MySQL 等）对以下一般情况下的最终顺序有何看法：

SELECT * FROM (SELECT * FROM Table t ORDER BY t.Field)

我可以相信内部顺序也受到外部投影的尊重，还是我需要ORDER BY在外部声明中明确说明？

我理解“明确列出”的建议。但是，在某些情况下，明确列出可能会导致问题。一方面，PostgreSQL 要求 中列出的所有字段也都列在ORDER BY中SELECT DISTINCT。在某些情况下这不好，因为它改变了预期的结果集，根据我感兴趣的单列，它不再是不同的。

我在 5.6.35-81.0 Percona Server 上有一个大型 MySQL 表，主键中有间隙。该表有大约 5300 万条记录，自动增量键现在约为 3.7 亿条。该表是电话号码列表，用户添加/删除号码非常频繁，因此 BIGINT 的 PRIMARY 键内部有间隙。

我现在面临的问题是，当我做一个简单的 SELECT * FROM 表时，MySQL 默认不使用 PRIMARY 键对结果进行排序。它使用表中的电话号码字段对数据进行排序，因此数据被按顺序选择，而不是按顺序保存在数据库中。

带有 ORDER BY id 的 Offcourse SELECT 需要很长时间。另一种解决方案是将所有数据复制到另一个表，但这需要应用程序停机。我怎样才能解决这个问题或在未来避免这种情况？

CREATE TABLE `contacts` (
  `id` bigint(20) NOT NULL AUTO_INCREMENT,
  `phonebook_id` int(11) NOT NULL,
  `campaign_id` int(11) DEFAULT NULL,
  `contact` varchar(45) NOT NULL,
  `status` tinyint(1) unsigned NOT NULL DEFAULT '1',
  `admin` tinyint(1) unsigned NOT NULL DEFAULT '0',
  `call_status` tinyint(1) unsigned NOT NULL DEFAULT '1',
  `active_call` tinyint(1) unsigned NOT NULL DEFAULT '0', …

MySQL 3.23/4.0/4.1 和 5.1 状态：

如果您使用GROUP BY [ for select]，则输出行将根据列进行排序，GROUP BY就像您ORDER BY对相同的列使用an一样。？？？

但是，MySQL 5.5 声明：

GROUP BY在 MySQL 5.5 中依赖隐式排序已被弃用。要实现分组结果的特定排序顺序，最好使用显式ORDER BY子句。？？？

（以上信息也在 5.6和5.7 中说明。）

MySQL 中的“已弃用”究竟是什么意思？

隐式的行为是否group by仍然保证在 MySQL 5.5、5.6 和 5.7（当前最新版本）上工作，就像之前的每个版本一样？

是否ORDER BY NULL仍然需要从做不必要的排序停止MySQL的？

编辑（由里克詹姆斯）

这包括数据库问题：

• 的排序GROUP BY，而不ORDER BY
• 的意义和用处 ORDER BY NULL
• 使用“已弃用”“功能”的智慧
• MySQL手册中“deprecated”的含义（不仅仅针对这种情况）