我计划将质谱仪的扫描结果存储在 MySQL 数据库中，并想知道存储和分析这一数量的数据是否远程可行。我知道性能因环境而异，但我正在寻找粗略的数量级：查询需要 5 天还是 5 毫秒？

输入格式

每个输入文件包含一次光谱仪运行；每次运行都由一组扫描组成，每个扫描都有一个有序的数据点数组。有一些元数据，但文件的大部分由 32 位或 64 位整数或浮点数数组组成。

主机系统

|----------------+---------------------------------------|
| 操作系统 | Windows 2008 64 位 |
| MySQL 版本 | 5.5.24 (x86_64) |
| 中央处理器 | 2x 至强 E5420（共 8 核）|
| 内存 | 8GB |
| SSD 文件系统 | 500 GiB |
| 硬盘RAID | 12 TiB |
|----------------+---------------------------------------|

服务器上还有一些其他服务在使用可忽略的处理器时间运行。

文件统计

|-----------+--------------|
| 文件数| ~16,000 |
| 总尺寸| 1.3 TiB |
| 最小尺寸 | 0 字节 |
| 最大尺寸 | 12 GiB …

我有一个带有 InnoDB 数据库的 symfony 应用程序，它有 57 个表，大约 2GB。数据库的大部分大小驻留在单个表中（~1.2GB）。我目前正在使用 mysqldump 每晚备份数据库。

由于我的 comcast 连接，通常如果我手动运行转储，我与服务器的连接将在转储完成之前超时，导致我不得不重新运行转储。[我目前运行一个每晚执行转储的 cron，这仅适用于我手动运行的转储。]

有没有办法加快连接超时问题的转储，同时也可以限制服务器被这个进程占用的时间？

顺便说一句，我目前正在努力减少整个数据库的大小来解决这个问题。

我已经看到一些专用的 MySQL 服务器，它们只使用一个内核。我比 MySQL 的 DBA 更擅长开发，所以需要一些帮助

设置

服务器非常庞大，具有 OLAP/DataWarehouse (DW) 类型的负载：

• 主要：96GB RAM，8 核 + 单个 RAID 10 阵列
• 测试：32GB RAM，4核
• 最大的 DB 是 540 GB，总共大约 1.1TB，主要是 InnoDB 表
• Solaris 10 Intel-64
• MySQL 5.5.x

注意：最大的 DB 是从 OLTP DR 服务器复制的 DB，DW 就是从这里加载的。它不是完整的 DW：仅持续 6 个月到 6 周，因此它比 OLTP DB 小。

对测试服务器的观察

• 3 个独立的连接
• 每个都有一个并发的（和不同的） ALTER TABLE...DROP KEY...ADD INDEX
• 这 3 个表有 2.5、3.8 和 450 万行
• CPU 使用率上升到 25%（一个核心被最大化）并且不会更高
• 3 次 ALTER 需要 12-25 分钟（最小的一次需要 4.5 分钟）

问题

1. 需要什么设置或补丁才能允许使用多个内核？
   也就是说，为什么 …

我一直在阅读使用或不使用Guid和的原因int。

int更小、更快、更容易记住、保持时间顺序。至于Guid，我发现的唯一优点是它是独一无二的。在哪种情况下 aGuid会更好int，为什么？

从我所看到的，int除了数量限制之外没有任何缺陷，这在许多情况下是无关紧要的。

究竟为什么被Guid创造？我实际上认为它除了用作简单表的主键之外还有其他用途。（任何Guid用于某事的实际应用程序的示例？）

_{SQL Server 上的 ( Guid = UniqueIdentifier ) 类型}

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

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

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

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

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

我有一个 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 命令行中测量页面大小来帮助我调试？

假设我有一个包含字段A和的表B。我在A+上进行常规查询B，所以我在 上创建了一个复合索引(A,B)。A复合索引是否也会对查询进行全面优化？

此外，我在 上创建了一个索引A，但 Postgres 仍然只使用复合索引来查询A。如果前面的答案是肯定的，我想这并不重要，但是为什么它默认选择复合索引，如果单个A索引可用？

我一直在为不同的公司工作，我注意到他们中的一些人更喜欢拥有将所有“亲戚”加入表格的视图。但是在应用程序中，有时我们只需要使用 1 列。

那么只进行简单的选择，然后将它们“加入”到系统代码中会更快吗？

该系统可以是 php、java、asp 或任何连接到数据库的语言。

所以问题是，从服务器端（php、java、asp、ruby、python...）到数据库并运行一个查询来获取我们需要的一切或从服务器端到数据库并运行哪个更快？一次只从一个表中获取列的查询？

考虑一下SO 上的这个答案，它使询问者对<>运营商感到放心：

<>是 ... 与 相同!=。

但随后一位评论者插嘴说：

确实，它们在功能上是相同的。但是，SQL 优化器如何使用它们是非常不同的。=/!= 被简单地评估为真/假，而 <> 意味着引擎必须查看该值是大于还是小于，这意味着更多的性能开销。只是在编写可能很昂贵的查询时需要考虑的事情。

我相信这是错误的，但为了解决潜在的怀疑论者，我想知道是否有人可以提供权威或规范的来源来证明这些运算符不仅在功能上相同，而且在所有方面都相同？

[敬礼]

（检查一个）

[ ] Well trained professional, [ ] Casual reader, [ ] Hapless wanderer,

我有一个（检查所有适用的）

[ ] query [ ] stored procedure [ ] database thing maybe  

运行良好（如果适用）

[ ] yesterday [ ] in recent memory [ ] at some point 

但现在突然变慢了。

我已经检查过以确保它没有被阻止，并且它不是某些长时间运行的维护任务、报告或其他带外进程的受害者。

有什么问题，我应该怎么做，我可以提供哪些信息来获得帮助？

[*Insert appropriate closing remarks*]