标签: innodb

我有一个 Django 应用程序，其中 InnoDB 中默认的“REPEATABLE READ”事务隔离级别导致不同的进程具有与数据库中当前数据不同的数据视图。

例如，进程 1 已进行更改，但进程 2 没有看到它。

我不需要应用程序中的交易完整性；我可以完全关闭事务，以便所有执行 SELECT 的进程看到相同的数据吗？

这样做有什么缺点吗？

这就是“READ UNCOMMITTED”的意思吗？

欢迎任何指点雷切尔

我尝试 rake db:schema:load 但收到错误

Mysql2::Error: Specified key was too long; max key length is 767 bytes: CREATE UNIQUE INDEX 

据我了解，InnoDB 索引中最多只允许 767 个字节......如果你使用 utf-8，它应该除以 3。

但是当我尝试在 schema.rb 中设置最大 100 个字符（甚至不接近 767）时，错误仍然发生......

模式.rb

add_index "friendly_id_slugs", ["slug", "sluggable_type"], :name => "index_friendly_id_slugs_on_slug_and_sluggable_type", :unique => true, :length => { :name => 100, :slug => 100, :sluggable_type => 40 }

错误

-- add_index("friendly_id_slugs", ["slug", "sluggable_type"], {:name=>"index_friendly_id_slugs_on_slug_and_sluggable_type", :unique=>true, :length=>{:name=>100, :slug=>100, :sluggable_type=>40}})
rake aborted!
Mysql2::Error: Specified key was too long; max key length is 767 bytes: CREATE …

我有一个存储电子邮件通信的表。每次有人回复时，跟踪的整个内容也会被包含并保存到数据库中（我需要这种方式，因为要纠正的应用程序级别更改的数量会太高）。

文本列的大小mail为10000。但是，我在存储文本时遇到的困难还不止于此。由于我不确定可以发生多少个通信，因此我不知道该专栏的最佳数量是多少。

发动机是InnoDB. 我可以使用某种列压缩技术来MySQL避免增加列的大小吗？

而且，如果我继续将 varchar 列增加到 20000，会怎么样。该表大约有 200 万条记录。这是一件好事吗？

我在mysql中有一个大InnoDB表。问题是我的磁盘空间几乎已满。我想减少磁盘空间。如果我要从表中删除一些行并使用以下命令：

optimize TABLE_NAME

那么我的磁盘空间将会减少。但我想放下桌子。如果我删除该表，则没有任何表可以对其进行优化！删除表后减少磁盘空间的适当命令是什么InnoDB？

当从MyISAM切换到InnoBD时，我使用了默认设置。阅读优化提示后，我意识到每个表最好放在单独的文件中。如何将表从一个文件传输到每个表模式的单独文件中？

我需要Contains在列中执行操作。对于包含操作，我们需要在单词前后使用通配符。

例如：个性化

查询 -> like '%sonal%'

因为这种类型的查询不能使用索引。有什么办法可以提高搜索速度。

注意：我使用MySql(InnoDB)和PSQL

让我用一个 SQL 示例来开始我的问题。

这是表设置：

1. 创建表x和y. 与y.x指x.id。
2. 将一行插入x(id=1)。

START TRANSACTION;
CREATE TABLE `x` (
    `id` INT(11) NOT NULL AUTO_INCREMENT,
    `value` INT(11) NOT NULL,
    PRIMARY KEY (`id`)
)  ENGINE=INNODB;
CREATE TABLE `y` (
    `id` INT(11) NOT NULL AUTO_INCREMENT,
    `x_id` INT(11) NOT NULL,
    `value` INT(11) NOT NULL,
    PRIMARY KEY (`id`),
    CONSTRAINT `fk_x` FOREIGN KEY (`x_id`)
        REFERENCES `x` (`id`)
)  ENGINE=INNODB;

INSERT INTO x values (1,123456);
COMMIT;

现在启动一个事务 (Trx A) 来更新 中的行x。 …

我已将虚拟生成的列添加到测试员工数据库中的工资表中，如下所示：

ALTER TABLE salaries
    ADD COLUMN salary_k int AS (salary / 1000);

现在，当我查询INFORMATION_SCHEMA.COLUMNS该EXTRA列时，该列按预期显示VIRTUAL GENERATED，但如何获取生成列的详细信息，即在本例中(salary / 1000)？ COLUMN_DEFAULT显示NULL.

SHOW CREATE TABLE salaries显示结果中的详细信息，但我希望结果作为较大查询的一部分INFORMATION_SCHEMA，因此这对我不起作用。

我正在学习 MySQL 架构。我想出了以下插图：

有4个我不太理解的概念：

• 双写缓冲区
• 日志缓冲区
• 预写日志
• 重做日志

我从很多文档中看到，Write-Ahead Log (WAL) 是一种数据库持久性机制。MySQL WAL 设计 维基百科 WAL

像上图一样，将数据从内存缓冲池刷新到磁盘时有两种类型的缓冲区：双写缓冲区和日志缓冲区。为什么我们需要 2 个缓冲区，它们与 WAL 有什么关系？

最后但并非最不重要的是，重做日志和 WAL 之间有什么区别。我认为 WAL 可以在发生错误时帮助数据库恢复（例如：停电、服务器崩溃......）。我们需要什么与 WAL 一起重做日志？

我们有一个包含数百万个条目的大表。完整计数非常慢，请参见下面的代码。这对于 MySQL InnoDB 表来说很常见吗？难道就没有办法加速这个过程吗？即使使用查询缓存，它仍然“慢”。我还想知道，为什么具有 2.8 mio 条目的“通信”表的计数比具有 4.5 mio 条目的“事务”表的计数慢。

我知道使用 where 子句会快得多。我只是想知道表现不佳是否正常。

我们使用 Amazon RDS MySQL 5.7 和 m4.xlarge（4 个 CPU、16 GB RAM、500 GB 存储）。我也已经尝试过使用更多 CPU 和 RAM 的更大实例，但查询时间没有大的变化。

mysql> SELECT COUNT(*) FROM transaction;
+----------+
| COUNT(*) |
+----------+
|  4569880 |
+----------+
1 row in set (1 min 37.88 sec)

mysql> SELECT COUNT(*) FROM transaction;
+----------+
| count(*) |
+----------+
|  4569880 |
+----------+
1 row in set (1.44 sec)

mysql> SELECT COUNT(*) FROM communication;
+----------+
| count(*) …