看看下面的sqlfiddle：http ://sqlfiddle.com/#!2/dacb5/1
CREATE TABLE contacts
(
id int auto_increment primary key,
name varchar(20),
network_id int,
network_contact_id int
);
INSERT INTO contacts
(name, network_id, network_contact_id)
VALUES
('John', 4, 10),
('Alex', 4, 11),
('Bob', 4, 12),
('Jeff', 4, 45),
('Bill', 7, 11),
('Walter', 7, 45),
('Jessie', 7, 360) ;
我有一个基本的联系人表。该network_id和network_contact_id字段包含链接到其他表的ID号码。
我希望能够运行INSERT IGNORE查询，此表，但我想用的组合network_id，并network_contact_id作为唯一键来匹配。
因此，举例来说，如果我试图插入一个接触的是有network_id = 4和network_contact_id = 12中，INSERT IGNORE查询将看到该条目已经存在，而忽略被抛出任何错误。
所以基本上，network_id不是唯一的。network_contact_id不是唯一的。但两者的结合是独一无二的。我该如何设置？我是否必须有一个其他字段作为其他两个字段的串联值？或者有没有办法为此表设置密钥，以便它可以满足我的需要？
在表中插入值后实时检索最新的guid值
不知道怎么做
CREATE TABLE [AddressBook]
(
[testID] [uniqueidentifier] NOT NULL default newid(),
[address] [nvarchar](50) NULL,
[zipcode] [nvarchar](50) NULL
)
我最近了解了工作中如何在数据库中定义关系，并想知道这是否是一种标准做法。
假设我们有两个进程：进程 A 和进程 B。进程 B 取决于进程 A 的结果，因此需要在进程 B 运行和进程 A 运行之间定义关系。关系是这样定义的：
TableProcessA:
Id
和
TableProcessB:
Id
ProcessAId
现在，到目前为止，事情对我来说是有道理的，但后来我和我对表格设计的理解变得有点奇怪。每当在 TableProcessA 或 TableProcessB 中创建一行时，都会调用一个函数，为每个创建一个全局唯一的 id。所以基本上，TableProcessA 和 TableProcessB 中的所有 Id 字段都不会包含任何匹配项，因为 Id 不仅对其表是唯一的，而且对整个数据库也是唯一的。
我的问题是，这有多标准？我的想法是每个表都应该有一个自动递增的 id，这个 id 只对表是唯一的，而不是整个数据库。
根据关于 UniqueIdentifier 的 microsoft 文档，此值始终是全局唯一的，因为它基于网络时钟和 CPU 时钟时间，另一方面，相同的文档说
uniqueidentifier 列可能包含多次出现的单个 uniqueidentifier 值，除非还为该列指定了 UNIQUE 或 PRIMARY KEY 约束。
我无法得出唯一标识符（GUID）如何在全球范围内唯一的结论，因为网络地址（Mac 地址）在两个不同的网络上可以是相同的，GUID 如何在全球范围内使用哪些组合是唯一的，以及为什么微软在那里说应该是主要或唯一约束，以确保我们始终具有唯一的 UniqueIdeitifer 值。
https://technet.microsoft.com/en-us/library/ms190215(v=sql.105).aspx
在表中，例如用户表，对于任何特定用户，只有 1 行带有 a，为什么要有 ID 字段，更不用说作为主键了？
寻找对这些人的一些专家意见 - 我不是一名 DBA，因此希望得到任何建议。不需要对架构的其余部分进行评论，因为它纯粹是为了说明我的问题而捏造的。
基本上，我正在为现有系统开发新功能，但无法更改现有架构。因此，假设当前有一个Users表，它具有一个类型为uniqueidentifier的主键UserID。我想创建一个名为Alerts的新表- 以一对多关系与 Users 表相关（一个用户可以有多个警报）。警报将通过此外键定期查询。我希望索引该字段以提高性能。
我的问题是 - 根据我对索引策略的理解，对 uniqueidentifier 列进行索引（巧妙地放置）不是一个好主意 - 所以有一个中间表来将这些 uniqueidentifier 键映射到更好的索引候选像一个更好的主意吗？整数？
用户
警报
或者
用户
用户地图
警报
我有一个大约有 600 万行的现有表。相关栏目有：
ID int not null PK
Key uniqueidentifier not null
通过Key查找对该表的读/写可能类似于 100 比 1。
现有的行都是使用创建的，newid()所以它们没有顺序。存在一个索引Key。
CREATE NONCLUSTERED INDEX [idx_Robert] ON [dbo].[Aleksander]
(
[Key] ASC
) WITH (PAD_INDEX = OFF
, STATISTICS_NORECOMPUTE = OFF
, SORT_IN_TEMPDB = OFF
, DROP_EXISTING = OFF
, ONLINE = OFF
, ALLOW_ROW_LOCKS = ON
, ALLOW_PAGE_LOCKS = ON
, FILLFACTOR = 80
) ON [PRIMARY]
鉴于表中已经有数百万行，将 GUID 生成更改为顺序使用有什么好处newsequentialid()？
展望未来，它将生成更好的数据，但由于不知道新的顺序 GUID 系列将在索引中的哪个位置，它会更快地破坏索引吗？将 GUID 生成保留为非顺序是否会更好，以便索引中的剩余页面空间更均匀地填充？
就表的增长率而言，它代表了大约3年的数据。
Year …我需要找到一种方法来识别 SQL 实例，无论对运行它的 SQL Server 和/或 Windows Server 进行了哪些更改，因为我们正在将有关实例的远程信息收集到我们的操作数据库中，并且仍然遇到我们正在使用的方法识别它并不像它看起来那么独特。
例如，如果我有服务器 WIN1\SQL 并且由于服务器刷新将安装在不同的服务器 WIN2\SQL 上，迁移数据并交换服务器名称，以便 WIN2\SQL 将变为 WIN1\SQL，反之亦然，我需要能够识别当前的 WIN1\SQL 与以前的 WIN1\SQL 不同 忽略操作系统版本和/或 SQL 版本\补丁级别
已经尝试以下：
NetworkName\InstanceName - 一直工作到服务器主机名\网络名称由于服务器刷新而改变，如上所述
SQL Server SID - 我正在寻找一些像 Windows 一样的 SQL 安装的 SID，但似乎没有这样的东西真的存在
##MS_SQLAuthenticatorCertificate## 的 SID - 这是我找到的最后一张最佳照片，扫描了数百个 SQL Server，它真的很独特 - 我以为我终于找到了它，直到我将 Service Pack 应用于一台服务器并发现 SID 已更改
任何想法如何唯一标识 SQL 实例（如 SQL 实例 SID）将不胜感激，因为我迷路了
编辑：我不是在管理所有 SQL 服务器。无法对超出范围的设备进行修改，因此寻找一些可以在 SQL2005+ 上运行的“内置”方式
因此，我们最近对以 auniqueidentifier作为主键的表中的插入运行了一些逻辑测试。这是我的测试查询；
IF OBJECT_ID('tempdb..#DatabaseTable') IS NOT NULL DROP TABLE #DatabaseTable
CREATE TABLE #DatabaseTable
([ID] [uniqueidentifier] NOT NULL PRIMARY KEY,
[LastUpdate] [datetime] NOT NULL,
[Locked] [tinyint] NOT NULL)
IF OBJECT_ID('tempdb..#temptable') IS NOT NULL DROP TABLE #temptable
CREATE TABLE #temptable (ID varchar(36), Data nvarchar(max))
INSERT INTO #temptable (ID, Data)
VALUES ('g078f19e-e150-4bb9-b5f4-b20b3fc64016', 'text goes here')
SELECT tmp.ID ,tmp.Data
FROM #temptable tmp
LEFT JOIN #DatabaseTable db
ON tmp.ID = db.ID
WHERE db.ID is null
这将失败，因为 uniqueidentifier 无效，因为它包含不正确的 'g' 值，该值超出了此数据类型的可接受范围。发生这种情况是因为开发人员为了测试手动更改了它，因为他知道目标表中不存在它，但不知道有效的字符列表。
这是它抛出的错误； …
我发现自己处于继承了数据库的情况，人们抱怨数据库性能。我确定了大约十几个没有聚集索引或没有精心规划的聚集索引的表，其中一些数据量大且经常使用。我实际上正在努力找出为堆实现 CI 的最佳候选者。经过大量阅读后，我仍然不知道该怎么做。我知道这取决于。所以我想给出一张表作为样本，希望得到一些建议。
该表有 122 列。是的，我知道...它包含大约 800 000 行。结构（摘录）：
CREATE TABLE [dbo].[tO](
[ID] [uniqueidentifier] NOT NULL,
[MaID] [uniqueidentifier] NULL,
[OrID] [uniqueidentifier] NOT NULL,
[UsID] [uniqueidentifier] NOT NULL,
[CrUsID] [uniqueidentifier] NOT NULL,
[SuID] [uniqueidentifier] NULL,
[SOID] [uniqueidentifier] NULL,
[DeA1ID] [uniqueidentifier] NULL,
[DeA2ID] [uniqueidentifier] NULL,
[PayID] [uniqueidentifier] NULL,
[MAdID] [uniqueidentifier] NULL,
[ShID] [uniqueidentifier] NULL,
[SessID] [varchar](32) NULL,
[OrUID] [uniqueidentifier] NULL,
[PurOfUID] [uniqueidentifier] NULL,
[AddiUID] [uniqueidentifier] NULL,
[SupUID] [uniqueidentifier] NULL,
[PayTID] [uniqueidentifier] NULL,
[OPSID] [uniqueidentifier] NULL,
[StoRSID] [uniqueidentifier] NULL,
[PayMeID] [uniqueidentifier] NULL,
... …uniqueidentifier ×10
sql-server ×7
index ×2
mysql ×2
uuid ×2
index-tuning ×1
insert ×1
instance ×1
primary-key ×1
schema ×1
t-sql ×1