问题列表 - 第5页

如果我去mysql shell输入SELECT * FROM users我得到 -

+--------+----------------+---------------------------------+----------+-----------+--------------------+--------------------+
| USERID | NAME           | EMAILID                         | PASSWORD | USER_TYPE | CONTACT_ID_FKUSERS | COMPANY_ID_FKUSERS |
+--------+----------------+---------------------------------+----------+-----------+--------------------+--------------------+
|    137 | X              | b@cc.com                        | #        | ADMIN     |                166 |                110 |
|    138 | Kshitiz        | ksharma@aaa.com                 | asdf     | ADMIN     |                167 |                111 |
+--------+----------------+---------------------------------+----------+-----------+--------------------+--------------------+

Oracle sqlplus 显示——

USERID     NAME  EMAILID    PASSWORD   USER_TYPE  CONTACT_ID_FKUSERS COMPANY_ID_FKUSERS
---------- ----- ---------- ---------- ---------- ------------------ ------------------
137        X     b@cc.com   #          ADMIN …

我一直在我们的 MS SQL 数据库上运行一个自动索引工具（我修改了一个源自 Microsoft 的脚本，该脚本查看索引统计表 -自动自动索引）。从统计数据中，我现在有一个需要创建的索引的建议列表。

编辑： 上述索引从 DMV 获取信息，这些信息告诉您数据库引擎将用于索引的内容（如果它们可用），并且脚本采用 Top x 推荐（通过搜索、用户影响等）并将它们放在表中。

（上面的编辑部分摘自 Larry Coleman 的回答，以阐明脚本在做什么）

由于我是数据库管理员的新手，并且在网上进行了快速搜索，因此我不愿意冒险并盲目添加推荐的索引。但是，由于没有在该领域的经验，我正在寻找一些关于如何确定这些建议是否必要的建议。

我是否需要运行 SQL Profiler，还是检查查询表的代码更好？你还有什么建议吗？

Unix 时间戳是自 UTC 时间 1970 年 1 月 1 日午夜以来的秒数。

如何从 PostgreSQL 获取正确的 unix 时间戳？

与currenttimestamp.com和timestamp.1e5b.de相比时，我没有从 PostgreSQL 得到预期的时间：

这将返回正确的时间戳：

SELECT extract(epoch from now());

虽然这不会：

SELECT extract(epoch from now() at time zone 'utc');

我住在 UTC +02 时区。从 PostgreSQL 获取当前 unix 时间戳的正确方法是什么？

这将返回正确的时间和时区：

SELECT now();
              now
-------------------------------
 2011-05-18 10:34:10.820464+02

另一个对比：

select now(), 
extract(epoch from now()), 
extract(epoch from now() at time zone 'utc');
              now              |    date_part     |    date_part
-------------------------------+------------------+------------------
 2011-05-18 10:38:16.439332+02 | 1305707896.43933 | 1305700696.43933
(1 …

我有一个 PostgreSQL 表。select *很慢，但又select id好又快。我认为可能是行的大小非常大并且需要一段时间来运输，或者可能是其他一些因素。

我需要所有字段（或几乎所有字段），因此仅选择一个子集不是一个快速解决方案。选择我想要的字段仍然很慢。

这是我的表架构减去名称：

integer                  | not null default nextval('core_page_id_seq'::regclass)
character varying(255)   | not null
character varying(64)    | not null
text                     | default '{}'::text
character varying(255)   | 
integer                  | not null default 0
text                     | default '{}'::text
text                     | 
timestamp with time zone | 
integer                  | 
timestamp with time zone | 
integer                  | 

文本字段的大小可以是任意大小。但是，在最坏的情况下，不会超过几千字节。

问题

1. 有什么关于这叫“疯狂低效”的吗？
2. 有没有办法在 Postgres 命令行中测量页面大小来帮助我调试？

我们的常驻数据库专家告诉我们，数字表非常宝贵。我不太明白为什么。这是一个数字表：

USE Model
GO

CREATE TABLE Numbers
(
    Number INT NOT NULL,
    CONSTRAINT PK_Numbers 
        PRIMARY KEY CLUSTERED (Number)
        WITH FILLFACTOR = 100
)

INSERT INTO Numbers
SELECT
    (a.Number * 256) + b.Number AS Number
FROM 
    (
        SELECT number
        FROM master..spt_values
        WHERE 
            type = 'P'
            AND number <= 255
    ) a (Number),
    (
        SELECT number
        FROM master..spt_values
        WHERE 
            type = 'P'
            AND number <= 255
    ) b (Number)
GO

根据博客文章，给出的理由是

数字表真的是无价之宝。我一直使用它们来进行字符串操作、模拟窗口函数、用大量数据填充测试表、消除游标逻辑以及许多其他没有它们将非常困难的任务。

但我不明白这些用途到底是什么——你能提供一些引人注目的具体例子，说明“数字表”在 SQL Server 中为你节省了大量工作——以及为什么我们应该拥有它们？

所以我对调整 InnoDB 还很陌生。我正在慢慢地将表（在必要时）从 MyIsam 更改为 InnoDB。我在 innodb 中有大约 100MB，所以我将innodb_buffer_pool_size变量增加到 128MB：

mysql> show variables like 'innodb_buffer%';
+-------------------------+-----------+
| Variable_name           | Value     |
+-------------------------+-----------+
| innodb_buffer_pool_size | 134217728 |
+-------------------------+-----------+
1 row in set (0.00 sec)

当我去更改innodb_log_file_size值时（例如mysql 的 innodb 配置页面上的my.cnf注释将日志文件大小更改为缓冲区大小的 25%。所以现在我的 my.cnf 看起来像这样：

# innodb
innodb_buffer_pool_size = 128M
innodb_log_file_size = 32M

当我重新启动服务器时，出现此错误：

110216 9:48:41 InnoDB：初始化缓冲池，大小 = 128.0M
110216 9:48:41 InnoDB：缓冲池初始化完成
InnoDB：错误：日志文件 ./ib_logfile0 的大小不同 0 5242880 字节
InnoDB：比指定的.cnf 文件 0 33554432 字节！
110216 9:48:41 [错误] …

我只是对分片和复制的工作方式感到困惑。

根据我在文档中找到的定义：

复制：MongoDB 中的副本集是一组维护相同数据集的 mongod 进程。

分片：分片是一种跨多台机器存储数据的方法。

根据我的理解，如果我有 75 GB 的数据，然后通过使用复制（3 个服务器），它将在每台服务器上存储 75GB 数据，这意味着服务器 1 上有 75GB，服务器 2 上有 75GB，服务器 3 上有 75GB。（如果我错了，请纠正我）。

并且通过使用分片，它将在服务器 1 上存储为 25GB 数据，在服务器 2 上存储为 25GB 数据，在服务器 3 上存储为 25GB 数据。（对？）。

但是后来我在教程中遇到了这一行：

分片存储数据。为了提供高可用和数据一致性，在生产分片集群中，每个分片都是一个副本集

一个副本集大小为75GB，而分片大小为25GB，那么它们如何等价呢？

这让我很困惑。我想我错过了一些明显的东西。请帮我解决一下这个。

总是创建交易是一种不好的做法吗？

例如，为一个简单的SELECT?

在没有必要的情况下创建交易的成本是多少？

即使您使用的是像 那样的隔离级别READ UNCOMMITTED，这是否是一种不好的做法？

错误全文如下：

psql：无法连接到服务器：没有这样的文件或目录。服务器是否在本地运行并接受 Unix 域套接字“/tmp/.s.PGSQL.5432”上的连接？

这是我第二次在 Mac 上通过 Homebrew 设置 Postgresql，我不知道发生了什么。以前，它一直在工作。在某些时候，我一定是输入了一个把事情搞砸的命令。我不知道。现在，每当我从命令行输入 SQL 命令时，我都会收到上述消息。我已经运行了一个命令来检查服务器是否正在运行，但显然不是。如果我尝试使用

$ postgres -D /usr/local/pgsql/data

我收到以下错误：

postgres 无法访问服务器配置文件 "/usr/local/pgsql/data/postgresql.conf": No such file or directory

我已经通过 Homebrew 卸载并重新安装了 Postgresql，但问题仍然存在。我完全不知道如何让这个工作。任何帮助，将不胜感激。

我刚刚在仅安装了 VS2019 的计算机上安装了 SSMS 18 GA，当我尝试打开 SSMS 时，会出现启动画面，但随后进程退出。

使用-log参数运行 ssms 会显示一条错误消息：

包 [Task Scheduler Package] 的 CreateInstance 失败：源：“mscorlib”描述：无法加载文件或程序集“Microsoft.VisualStudio.Shell.Interop.8.0，版本=15.0.0.0，Culture=neutral，PublicKeyToken=b03f5f7f11d50a3a”或其中之一它的依赖。定位的程序集的清单定义与程序集引用不匹配。（来自 HRESULT 的异常：0x80131040） System.IO.FileLoadException：无法加载文件或程序集“Microsoft.VisualStudio.Shell.Interop.8.0，版本=15.0.0.0，Culture=neutral，PublicKeyToken=b03f5f7f11d50a3a”或其依赖项之一。定位的程序集的清单定义与程序集引用不匹配。（来自 HRESULT 的异常：0x80131040）文件名：'Microsoft.VisualStudio.Shell.Interop.8.0，版本=15.0.0.0，文化=中性，PublicKeyToken=b03f5f7f11d50a3a' ---> System.IO.FileLoadException：无法加载文件或程序集“Microsoft.VisualStudio.Shell.Interop.8.0，版本=8.0.0.0，Culture=neutral，PublicKeyToken=b03f5f7f11d50a3a”或其依赖项之一. 定位的程序集的清单定义与程序集引用不匹配。（来自 HRESULT 的异常：0x80131040）文件名：'Microsoft.VisualStudio.Shell.Interop.8.0，版本=8.0.0.0，Culture=neutral，PublicKeyToken=b03f5f7f11d50a3a'

警告：程序集绑定日志已关闭。要启用程序集绑定失败日志记录，请将注册表值 [HKLM\Software\Microsoft\Fusion!EnableLog] (DWORD) 设置为 1。注意：有一些与程序集绑定失败日志记录相关的性能损失。要关闭此功能，请删除注册表值 [HKLM\Software\Microsoft\Fusion!EnableLog]。

在 System.Reflection.RuntimeAssembly.GetType(RuntimeAssembly assembly, String name, Boolean throwOnError, Boolean ignoreCase, ObjectHandleOnStack type) at System.Reflection.RuntimeAssembly.GetType(String name, Boolean throwOnError, Boolean ignoreCase) at System.Activator.CreateInstance(String assemblyString, String typeName, Boolean ignoreCase, BindingFlags bindingAttr, Binder binder, Object[] args, CultureInfoculture, Object[] activationAttributes, Evidence securityInfo, StackCrawlMark& stackMark) at System.Activator.CreateInstance(String assemblyName, String typeName) at …