获取nginx的当前时间，为啥比电脑的时间多两个小时啊？怎么解决啊？

Posted 2023-05-15

参考技术A 获取时间的函数有很多，ngx.today(), ngx.time(), ngx.utctime(), ngx.localtime(), ngx.now()这些都很常用，ngx.now()这个函数返回的是时间戳的秒数，*1000就是毫秒了追问

我用的就是这个啊，的到时间比现在多出两个小时

参考技术B 这两不能同时运行,如果都用80,会有一个提示端口占用! 如果非要确定是那个软件,按么就抓包吧追问

我用的是8881端口，没有被占用，就是输出的时间比现在多整整两个小时，为什么啊

为啥复制表的大小比原来的小很多？

【中文标题】为啥复制表的大小比原来的小很多？

【英文标题】：Why is the size of duplicated table so much smaller than original?为什么复制表的大小比原来的小很多？

【发布时间】：2016-09-01 19:26:20

【问题描述】：

我有一个表 [ExampleSource]，其中 SQL Server Management Studio 指示以下存储统计信息：

索引空间：58 MB 行数：28269319 数据空间：4,567 MB

我使用以下命令复制了该表，目的是对各种索引配置进行基准测试：

SELECT * 
INTO [ExampleSource_Test] 
FROM [ExampleSource] 

查询一结束，我就注意到了一些令人惊讶的事情。新测试表中的数据量大大减小：

索引空间：0.016 MB 行数：28269319 数据空间：2,820 MB

新表有相同的数据，只是没有索引/主键。我在新的 Test 表中添加了一个主键（与原始键相同），结果如下：

索引空间：22.227 MB 行数：28269319 数据空间：2,820 MB

添加密钥不会增加数据空间也就不足为奇了。

如果有帮助，这里是表结构：

CREATE TABLE [dbo].[ExampleSource]
(
    [C1] [bigint] NOT NULL,
    [C2] [nvarchar](9) NOT NULL,
    [C3] [nvarchar](5) NOT NULL,
    [C4] [int] NOT NULL,
    [C5] [nvarchar](1) NOT NULL,
    [C6] [int] NOT NULL,
    [C7] [bit] NOT NULL,
    [C8] [date] NULL,
    [C9] [decimal](29, 9) NULL,
    [C10] [nvarchar](max) NULL,
    [C11] [nvarchar](1) NULL,
    [C12] [decimal](29, 9) NULL,
    [C13] [nvarchar](3) NULL,

    CONSTRAINT [PK_ExampleSource] 
       PRIMARY KEY CLUSTERED ([C2] ASC, [C3] ASC, [C4] ASC, [C5] ASC, [C6] ASC, [C1] DESC)
       WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, 
             IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, 
             ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
) ON [PRIMARY] TEXTIMAGE_ON [PRIMARY]

原始表是随着时间的推移多次插入行的结果 - 通常一次插入几千个。没有更新或删除。我想知道是什么导致了与原始表（索引和数据）的这种巨大空间差异？我猜测 SQL Server 在一次复制所有数据时正在对数据进行大量优化/重组，但我正在寻找一个很好的解释来解释为什么原始表中可能会浪费这么多空间。我可以/应该偶尔在桌子上进行一些维护以防止这种膨胀吗？

【问题讨论】：

旁注：nvarchar(1) 没用 - 请改用 nchar(1)。由于您最多只能存储 1 个字符，因此将其设为可变长度列只会增加每行 2 字节的开销（如果您使用 nchar(1) 代替，则不会产生这种开销）。 nvarchar(3)

也是如此

marc_s，我明白你关于 nvarchar(1) 的观点。但是，相同的逻辑仅从存储角度适用于 nvarchar(3)。如果我有可变长度的项目，我不想使用 nchar。修剪空白很烦人。

同意 - 但如果您存储 90% 以上的字符串总是只有 1 或 3 个字符长，这是值得的。

【参考方案1】：

一个可能的原因是原始表有一个或多个可变长度列被删除。在这种情况下，请尝试使用DBCC CLEANTABLE

第二个可能的原因是碎片，尝试用查询检查一下：

select a.index_id, name, avg_fragmentation_in_percent  
    from sys.dm_db_index_physical_stats (DB_ID(N'YourDatabase'), OBJECT_ID(N'ExampleSource'), NULL, NULL, NULL) a
    join sys.indexes AS b ON a.object_id = b.object_id AND a.index_id = b.index_id

如果有些索引是碎片化的，重新整理一下：

ALTER INDEX Index_name on Table_Name REORGANIZE WITH (LOB_COMPACTION=ON)

如果这没有多大帮助，请尝试使用“ALTER INDEX REBUILD”（最后选择删除并重新创建索引）。

【讨论】：

表结构自最初创建以来未更改。我很想尝试 DBCC CLEANTALBE，但您回答中链接的文章表明它“不应作为日常维护任务执行”。

可能索引碎片化（我刚刚编辑了答案）。即使您只是添加新行，这种情况（很少）也会发生。

查看编辑问题中的聚簇索引后，我认为问题很可能是由于插入过程中的分页造成的。

有没有办法检验这个假设？我还没有以任何方式修改原始表格。

首先，尝试从我的答案 (dm_db_index_physical_stats) 运行查询，您是否看到任何碎片？