我正在尝试学习表分区。但是,我很难理解为什么 SQL Server 会在一个简单的查询中表现出阶段性。
/* --------------------------------------------------
-- Create helper function GetNums by Itzik Ben-Gan
-- http://sqlmag.com/sql-server/virtual-auxiliary-table-numbers
-- GetNums is used to insert test data
-------------------------------------------------- */
-- Drop helper function if it already exists
IF OBJECT_ID('GetNums') IS NOT NULL
DROP FUNCTION GetNums;
GO
-- Create helper function
CREATE FUNCTION GetNums(@n AS BIGINT) RETURNS TABLE AS RETURN
WITH
L0 AS(SELECT 1 AS c UNION ALL SELECT 1),
L1 AS(SELECT 1 AS c FROM L0 AS A CROSS JOIN L0 AS …Run Code Online (Sandbox Code Playgroud) 转储一些内部视图,例如sys.system_objects在此问题中完成的我看到某些标识符以美元符号结尾$
CREATE VIEW sys.system_objects AS
-- cutout
FROM sys.sysschobjs$ o -- XXX: HERE
LEFT JOIN sys.syspalnames n
-- not relevant
Run Code Online (Sandbox Code Playgroud)
而且,这也有效
SELECT * FROM sys.sysschobjs$;
Run Code Online (Sandbox Code Playgroud)
即使只是按照惯例,这里的规则是什么?我应该在我自己的代码中使用它吗?
搜索我看到很多关于 Excel(无关)和 Money 文字(也无关)的内容。
我发布了另一个我认为无关的问题,但我相信这个终端$会对此有更多的了解。请随意检查该问题以获取一些混淆的示例
我在谷歌上搜索过这个但找不到,你可以看到Rick James在这里提到它。
......
BLOB而TEXT并不总是分开存放
在回答什么是MySQL的VARCHAR和TEXT数据类型之间的区别?说,
InnoDB 与 类似
VARCHAR,但将完整TEXT字段存储在记录之外。
对于这种立场,这并不是唯一获得大量支持的答案。从 StackOverflow你可以找到一个有754 个赞的答案,它说得很清楚,
TEXT并BLOB存储在表外,表只有一个指向实际存储位置的指针。
VARCHAR与表内联存储。VARCHAR当大小合理时更快,权衡更快取决于您的数据和您的硬件,您希望使用您的数据对现实世界的场景进行基准测试。
MyISAM 放置
TEXT并BLOB“内联”。如果您正在搜索表(范围扫描/表扫描),那么您就是在“跨过那些牛田”——磁盘 I/O 的成本很高。也就是说,在这种情况下,内联 blob 的存在会损害性能。InnoDB 只放入 767 字节的 a
TEXT或BLOBinline,其余部分放入其他块。这是一种有时会有所帮助,有时会损害性能的妥协。
我看过其他帖子,讨论在某些限制下存储文本和 blob 吗?限制是什么?InnoDB 什么时候(如果有的话)在行中存储 blob 和文本?
我们有一个带有两个实例的物理 SQL Server 2016 Enterprise SP2,每个实例包含一个 AG。有时会发生一个AG去resolve(没有failover),集群资源在500ms后自动重启,然后一切又重新上线。但是我还没有找到原因。
当我检查错误日志时,我看到以下条目:
日期 14/04/2019 23:35:37
SQL Server 托管可用性组“AG_PROD”在租用超时期限内未收到来自 Windows Server 故障转移群集的进程事件信号。日期 14/04/2019 23:35:37
SQL Server 托管可用性组“AG_PROD”在租用超时期限内未收到来自 Windows Server 故障转移群集的进程事件信号。日期 14/04/2019 23:35:14
SQL Server 在数据库 ID 6 中的文件 [e:\sqlData\db.mdf] 上遇到了 1 次 I/O 请求需要超过 15 秒才能完成。操作系统文件句柄是 0x0000000000001128。最新的long I/O的偏移量为:0x00010de65c0000日期 14/04/2019 23:33:10
BACKUP DATABASE WITH DIFFERENTIAL 在 61.045 > 秒(6.585 MB/秒)内成功处理了 51459 页。
如您所见,有一个 IO 请求需要的时间超过 15 秒,我希望能在*_SQLDIAG_*.xel文件中找到它,但此处未发现任何错误。
当我检查集群日志时,我发现以下内容:
2019/04/14-23:35:09.430 INFO [NM] 收到来自客户端地址 SQL1 的请求。
2019/04/14-23:35:09.444 INFO [NM] 收到来自客户端地址 SQL1 的请求。
2019/04/14-23:35:09.459 …
clustering database-internals availability-groups sql-server-2016
是否可以在 T-SQL 更新语句中覆盖相同的磁盘地址?出于安全或匿名原因,用例将阻止恢复磁盘上的原始文本。
CREATE TABLE Test(
Id int,
Message nvarchar(1000))
GO
INSERT INTO Test (Id, Message) VALUES (1, 'Hello!')
GO
Run Code Online (Sandbox Code Playgroud)
所以在这一点上,“你好!” 写入磁盘。如果运行更新语句,是否可以保证(或至少很有可能)覆盖磁盘上的相同位置?
UPDATE Test SET Message = '000000' WHERE Id = 1
GO
Run Code Online (Sandbox Code Playgroud)
在 SQL Server 实现中,原始 'Hello!' 的概率是多少?价值将不再在磁盘上?
我假设新值的大小相同。我的猜测是,如果新值的大小不同,那么 SQL Server 会将更新后的值写入新位置,留下“你好!” 在原来的位置,但现在标记为免费。我还假设删除对磁盘上的原始值没有任何影响,而只是将该位置标记为空闲。
如果情况并非如此,或者不能保证,或者至少很有可能,是否有另一种方法可以从磁盘中删除该值?
这里的要求不是达到保护政府机密安全的程度。这更像是一种营销声明,即已删除的项目确实已经消失并且无法恢复。
我知道这里有很多警告。我知道 SQL 语言没有解决这个问题。我特别询问 SQL Server 的实现。答案可能是它是不可知的。只是想知道是否有文档或常识,或者是否有人测试了实现细节。
我们正在使用不加密 SQL Server 磁盘的托管服务。我们在写入数据库之前对值进行加密。只是在研究“腰带和牙套”解决方案。
给定 StackOverflow2010 数据库上的以下简单查询:
SELECT u.DisplayName,
u.Reputation
FROM Users u
JOIN Posts p
ON u.id = p.OwnerUserId
WHERE u.DisplayName = 'alex' AND
p.CreationDate >= '2010-01-01' AND
p.CreationDate <= '2010-03-01'
Run Code Online (Sandbox Code Playgroud)
我试图理解为什么创建索引
CREATE INDEX IX_CreationDate ON Posts
(
CreationDate
)
INCLUDE (OwnerUserId)
Run Code Online (Sandbox Code Playgroud)
产生更好的估计Posts.CreationDate
当我运行没有索引的查询时,我得到Plan 1。在此计划中,SQL Server 估计 Posts 上的 CI 扫描产生 298,910 行,实际上返回 552 行 - 这个估计值相差甚远。
添加索引后,我会得到Plan 2,这会导致索引查找和更准确的估计。
我很好奇为什么添加索引会导致更好的估计,因为当在谓词中使用列时会创建统计信息WHERE,无论它是否被索引。
经过进一步检查,我可以看到计划 1 与计划 2 上的谓词Posts.CreationDate不同:
计划 1 谓词
[StackOverflow2010].[dbo].[Posts].[CreationDate] as [p].[CreationDate]>='2010-01-01 00:00:00.000' AND [StackOverflow2010].[dbo].[Posts].[CreationDate] …Run Code Online (Sandbox Code Playgroud) sql-server execution-plan database-internals cardinality-estimates sql-server-2019
例如
SQL> create table dates(d date);
Table created.
SQL> insert into dates select sysdate from dual;
1 row created.
SQL> select * from dates;
D
---------
28-MAY-11
SQL> insert into dates (d) values (select sysdate fom dual);
insert into dates (d) values (select sysdate fom dual)
*
ERROR at line 1:
ORA-00936: missing expression
SQL>
Run Code Online (Sandbox Code Playgroud) 我们最近在多次接近中断后停用了一个实施得相当糟糕的服务代理设置,但是在我早上检查时,我注意到有 2 个服务代理内部 SPID (<50) 仍然持有约 75% 的 TempDB空间。
现在,我知道这些是服务代理任务,因为 SysProcesses 上的 CMD 列显示“BRKR EVENT HNDLR”和“BRKR TASK”,而最后的等待类型分别是“BROKER_EVENTHANDLER”和“SLEEP_TASK”。两者都将“背景”作为状态,0 开放交易和一个多月前的最后一批时间。
目前服务代理实现已完全禁用(从代码角度),队列已禁用(is_activation_enabled 和 is_receive_enabled = 0),transmission_queue、conversation_endpoints 或实际队列中没有任何内容,但有问题的数据库仍然有 is_broker_enabled = 1(与 TempDB 和 MSDB 一样)。
服务器当前正在运行带有安全修复程序 (11.0.5343.0) 的 SP2,即使在集群故障转移之后,TempDB 的使用似乎仍然存在。我们没有尝试重新启动,因为这是一个生产系统,但我认为故障转移会产生相同的效果。
以前有没有人遇到过这个问题,如果有,你是怎么解决的?
谢谢,
sql-server database-internals service-broker sql-server-2012 tempdb
我正在查看 TechNet 上列出的 SQL Server 物理运算符(不要判断,你知道你已经完成了)并读到哈希匹配物理运算符有时用于实现UNION逻辑运算符。
我从未见过这样做过,并想了解更多。一个示例查询会很棒。什么时候使用它,什么时候它比替代品更好?(这些通常是相同的,但并非总是如此。)
sql-server optimization execution-plan database-internals union
我使用的是 MariaDB 10.1 和默认的 InnoDB 存储,我有几个表,目前有 10 到 1 亿行。这些表将保持每月数百万的增长,而且主要是缓存。
它们要么有一个单列主键 ( BIGINT) 或一个复合主键(两BIGINT列),没有 AUTO_INCREMENT,我总是按主键插入、选择或更新。我还通过主键或 selects 进行了很多连接WHERE PK IN (1, 2, 3, 4...)。
此外,这些表每小时会收到大量更新,我通常一次以 5000 或 10000 个批次更新它们。对于其中一些表,我们有比选择更多的插入和更新。
我有3个问题:
在我看来,通过 PK 返回 1 行 ( SELECT x, y FROM table WHERE pk = 123) 的简单选择在性能上与分区没有实际差异。那正确吗?
加入或选择为WHERE PK IN(SELECT PK FROM ...)怎么样?与单个表相比,它会导致更多的扫描加入分区表吗?
考虑到我通常使用以下方法进行大量并发批处理(多个服务器可能同时发送数据):
INSERT INTO X VALUES (1, 'A'), (2, 'B'), ... ON DUPLICATE KEY UPDATE ... 或者
REPLACE INTO X VALUES(1, 'A'), …
sql-server ×6
mysql ×2
blob ×1
clustering ×1
innodb ×1
mariadb ×1
optimization ×1
oracle ×1
partitioning ×1
storage ×1
subquery ×1
tempdb ×1
union ×1
update ×1