小编Rol*_*DBA的帖子

我从未涉足 MySQL 集群，想知道它如何使我受益。什么时候使用它最好，它是否有性能优势？

我们有一个表，用于存储问题的答案。我们需要能够找到对特定问题有特定答案的用户。因此，如果我们的表包含以下数据：

user_id     question_id     answer_value  
Sally        1               Pooch  
Sally        2               Peach  
John         1               Pooch  
John         2               Duke

并且我们想要找到回答问题 1 的“Pooch”和回答问题 2 的“Peach”的用户，以下 SQL 将（显然）不起作用：

select user_id 
from answers 
where question_id=1 
  and answer_value = 'Pooch'
  and question_id=2
  and answer_value='Peach'

我的第一个想法是为我们正在寻找的每个答案自行加入表格：

select a.user_id 
from answers a, answers b 
where a.user_id = b.user_id
  and a.question_id=1
  and a.answer_value = 'Pooch'
  and b.question_id=2
  and b.answer_value='Peach'

这是有效的，但由于我们允许任意数量的搜索过滤器，我们需要找到更有效的东西。我的下一个解决方案是这样的：

select user_id, count(question_id) 
from answers 
where (
       (question_id=2 and answer_value = 'Peach') 
    or (question_id=1 and answer_value = 'Pooch')
      )
group …

背景

我有一个由大约 2000 个传感器组成的网络，每个传感器都有大约 100 个数据点，我们每隔 10 分钟收集一次。这些数据点通常是 int 值，但有些是字符串和浮点数。这些数据应该存储 90 天，如果可能的话，更多并且仍然有效。

数据库设计

当最初负责这个项目时，我编写了一个 C# 应用程序，为每个传感器编写逗号分隔的文件。当时没有那么多，当有人想查看趋势时，我们会在 Excel 中打开 csv 并根据需要绘制图表。

事情发展了，我们切换到了 MySQL 数据库。我为每个传感器创建了一个表格（是的，我知道，很多表格！）；它运行良好，但有一些限制。有这么多表，显然不可能编写一个查询，在查找特定值时会在所有传感器中查找数据。

对于下一个版本，我切换到 Microsoft SQL Server Express，并将所有传感器数据放入一个大表中。这也有效，并让我们进行查询以在所有感兴趣的传感器中查找值。但是，我遇到了 Express 版本的 10GB 限制，并决定切换回 MySQL 而不是投资 SQL Server Standard。

问题

我对 MySQL 的性能和可扩展性很满意，但我不确定坚持所有数据在一个表中的方法是否最好。单个表中的 10GB 似乎要求不同的设计。我应该提到的是，仍然需要查询数据以绘制图形，而且我担心绘制图形的查询会出现性能问题，例如，一个传感器在整个 90 天内的温度数据。（换句话说，图形应该是快速生成的，而无需等待 SQL 对成堆的数据进行排序以隔离感兴趣的传感器。）

我应该以某种方式拆分此表以提高性能吗？或者有这么大的桌子也不是什么稀奇事？

我在 Sensor ID 和 Timestamp 列上有索引，这几乎是任何查询的定义边界。（即从时间 A 到时间 B 获取传感器 X 的数据）。

我已经阅读了一些关于分片和分区的内容，但在这种情况下不觉得这些是合适的。

编辑：

根据到目前为止的评论和答案，一些额外的信息可能会有所帮助：

非无限期存储：目前我不存储超过 90 天的数据。每天，我都会运行一个查询来删除超过 90 天的数据。如果将来它变得重要，我会存储更多，但现在已经足够了。这有助于控制大小和高性能（呃）。

引擎类型：最初的 MySQL 实现使用了 MyISAM。这次为新实现（一个数据表而不是多个）创建表时，他们默认为 InnoDB。我不相信我对其中一个有要求。

归一化：当然还有除了数据采集表之外的其他表。这些支持表存储诸如传感器的网络信息、用户的登录信息等内容。没有太多需要规范化的内容（据我所知）。数据表有这么多列的原因是每个传感器有这么多变量。（多个温度、光照水平、气压等）对我来说标准化意味着没有冗余数据或重复组。（至少对于 1NF。）对于给定的传感器，在特定时间存储所有值需要一行数据，并且那里不涉及 1:N 关系（我看到）。 …

我有一个包含多个表的数据库。

我想从表中删除一些记录，说记录数超过 20K 或 50K。

所有的表都是 InnoDB。并且file_per_table是关闭的。

当我从多个表中删除记录时，表中会出现碎片。

有没有办法消除碎片。？

4月17日更新

mysql> select TABLE_NAME, TABLE_SCHEMA, Data_free from information_schema.TABLES where TABLE_SCHEMA NOT IN ('information_schema', 'mysql') and Data_Free >0;
+-----------------+--------------+-----------+
| TABLE_NAME      | TABLE_SCHEMA | Data_free |
+-----------------+--------------+-----------+
| City            | world_innodb |   5242880 |
| City_Copy       | world_innodb |   5242880 |
| Country         | world_innodb |   5242880 |
| CountryLanguage | world_innodb |   5242880 |
| a               | world_innodb |   5242880 |
| t1              | world_innodb |   5242880 …

我有一个包含产品描述的表格，每个产品描述都有一个product_id和language_id。我想要做的是用 a language_idof更新所有字段，2使其product_id与language_idis相同1。

到目前为止，我已经尝试了以下查询，但是我收到的错误表明 MySQL 不想更新在子查询中也使用了该表的表。

UPDATE
  products_description AS pd
SET 
  pd.products_seo = (
    SELECT
      pd2.products_seo
    FROM 
      products_description AS pd2
    WHERE
        pd2.language_id = 1
    AND pd2.products_id = pd.products_id
  )
WHERE
  pd.language_id <> 1

在 MySQL 中是否有“简单”的方法来解决这个限制？还是有什么“技巧”？我有点惊讶我的查询不起作用，因为这似乎是合乎逻辑的。

我看到我可以在 mysql/innodb 中查看最新的死锁，但是有没有办法查看过去的死锁？我们有两个僵局问题，一个很重要，另一个不重要。不太重要的僵局一天发生几次，因此它成为“最新”的僵局。

为什么我的还原操作不起作用？

我使用以下方法为数据库创建了一个转储文件：

mysqldump -u root -p databasename > /home/databasename_bkup.sql  

然后我打开了 dumfile 并确认它包含CREATE TABLE数据库中每个表的语句。因此，在运行以下恢复命令之前，我删除了数据库并重新创建了一个同名的空数据库：

mysqldump -u root -p databasename < /home/databasename_bkup.sql  

此恢复命令导致在终端中打印以下内容：

-- MySQL dump 10.13  Distrib 5.6.23, for Linux (x86_64)
--
-- Host: localhost    Database: databasename
-- ------------------------------------------------------
-- Server version   5.6.23

/*!40101 SET @OLD_CHARACTER_SET_CLIENT=@@CHARACTER_SET_CLIENT */;
/*!40101 SET @OLD_CHARACTER_SET_RESULTS=@@CHARACTER_SET_RESULTS */;
/*!40101 SET @OLD_COLLATION_CONNECTION=@@COLLATION_CONNECTION */;
/*!40101 SET NAMES utf8 */;
/*!40103 SET @OLD_TIME_ZONE=@@TIME_ZONE */;
/*!40103 SET TIME_ZONE='+00:00' */;
/*!40014 SET @OLD_UNIQUE_CHECKS=@@UNIQUE_CHECKS, UNIQUE_CHECKS=0 */;
/*!40014 SET @OLD_FOREIGN_KEY_CHECKS=@@FOREIGN_KEY_CHECKS, FOREIGN_KEY_CHECKS=0 */;
/*!40101 …

我正在考虑为我的数据库设置主从复制。从服务器将用于冗余和可能的报告服务器。但是，我遇到的最大问题之一是我们的数据中心已经用尽了电源。因此，添加另一台物理服务器不是一种选择。

就 CPU 而言，我们现有的数据库服务器的利用率相当低（四核上的平均负载从未真正超过 1）。所以主要的想法是放入一些新驱动器并将内存加倍（从 8GB 到 16），并在同一台物理机器上运行第二个 mysql 实例。每个实例都有单独的数据库磁盘。

这个想法有什么问题吗？

编辑（更多信息）：我（幸运的是）从来没有发生过任何足以关闭服务器的事情，但我正在努力提前计划。我们当然有可以从中恢复的每晚备份。但我认为，如果主服务器的驱动器出现故障（如果整台机器出现故障，显然不会），将冗余数据放在单独的磁盘上会提供更快的解决方案。

至于报告方面，我们要报告的任何表都是 MyIsam。因此，在正在写入的同一表上进行昂贵的读取可能会使服务器陷入困境。我的假设是，只要我们在主服务器上投入足够的 RAM（因为 cpu 负载还不是问题），有一个要报告的从服务器就不会影响主服务器。

学习如何操作和管理 MongoDB的最佳资源是什么？

有很多资源可以针对它进行开发 - 当您拥有足够的开发能力并且确实需要过滤掉这些噪音时，这实际上会产生问题。对于还没有能力聘请 DBA 的开发人员，我们需要在保持我们的 Mongo 集群稳定、高性能等方面做得相当好。除了常见问题解答和快速入门指南之外，还有其他好的信息存储库吗？值得关注的好博客等？

我有点像一个新的 DBA，我正在管理一个具有大量活动的 SQL Server 2012 实例。我在完全恢复模式下运行，因为我们需要时间点恢复。

现在，我每天凌晨 5 点对数据库和日志进行完整备份。一些日志文件已经膨胀到 300gb，即使在进行备份后，它们的大小也不会减小。我可以通过运行类似于以下内容的内容来减小它们的大小：

BACKUP LOG db1 TO DISK = '\\server\share\db1_log1.trn';
DBCC ShrinkFile([db1_log], 0);

BACKUP LOG db1 TO DISK = '\\server\share\db1_log2.trn';
DBCC ShrinkFile([db1_log], 0);

BACKUP LOG db1 TO DISK = '\\server\share\db1_log3.trn';
DBCC ShrinkFile([db1_log], 0);

当我检查备份文件的 LSN 时，我看到如下内容：

RESTORE headeronly FROM DISK = N'\\server\share\db1_log1.trn'
FirstLSN:  15781000014686200001
SecondLSN: 15802000000665000001

RESTORE headeronly FROM DISK = N'\\server\share\db1_log2.trn'
FirstLSN:  15802000000665000001
SecondLSN: 15805000000004100001

RESTORE headeronly FROM DISK = N'\\server\share\db1_log3.trn'
FirstLSN:  15805000000004100001
SecondLSN: 15808000000004200001

我不相信我通过缩小日志文件来破坏我的日志链。读到这里，我确实相信我正在损害我的性能，因为那些缩小的日志文件必须重新增长自己。

问题：

1. 为什么备份后日志文件没有缩小？是因为有未提交的事务吗？
2. 起初我想我应该在每 5:00 AM 备份后缩小日志文件。在阅读了这对性能的影响之后，我现在相信我需要在白天每隔几个小时进行一次定期的日志备份。那是对的吗？ …