本文对应原书第5章-优化服务器设置。出乎意料的是，该章节建议正确地配置基本设置，并将更多的时间花在schema优化、索引和查询设计上。甚至有innodb_dedicated_server这种自动配置 MySQL 的选项。

限于本人水平不足，本文只是对相关配置的分类整理，列出的配置无法给出测试。文章的最后展示了自己使用的最小资源配置，仅供参考。



## 什么不应该做

**建立基准测试套件**

它需要大量的工作和研究，而且大多时候，潜在的回报非常小，因此是巨大的时间浪费。最好把这些时间花在其他事情上，比如检查备份、监控查询计划的变化等。

**按比率调优**

调优比率是一个经验法则。比如，InnoDB缓冲池命中率应该高于某个百分比，如果命中率过低，应该增加缓存大小。这是非常错误的建议。缓存命中率与缓存是太大还是太小无关。
- 命中率取决于工作负载。不管缓存有多大，有些工作负载根本不能被缓存
- 缓存命中是没有意义的。

**使用调优脚本**

“调优”服务器可能是一种惊人的时间浪费。在没有经过测试和理解的情况下进行应用也可能是危险的，因为它可能针对的是一种与你不同的情况，而你却没有理解。

**相信流行的内存消耗公式**

MySQL本身在崩溃时会输出的那个公式（没听说过，反正不建议用）。这个公式是很早之前的。这不是一个可靠的，甚至不是一个有用的方法来了解MySQL在最坏的情况下可以使用多少内存。事实是，你不能给MySQL的内存消耗设定上限。MySQL并不是一个严格控制内存分配的数据库服务器。

## 配置介绍

确定配置文件位置
```shell
$ mysqld --verbose --help | grep -A 1 'Default options'
Default options are read from the following files in the given order:
/etc/my.cnf /etc/mysql/my.cnf /usr/etc/my.cnf ~/.my.cnf
```

配置文件格式
- MySQL 配置文件是 INI 标准
- 配置项全部使用小写字符，单词之间用下划线或短横线（等效的）。

配置项是有作用域的
- 全局作用域（服务器）
- 会话作用域（连接）
- 对象作用域

能够在服务器运行时更改的配置称为动态配置变量，MySQL 重启后会失效。
- 如果在服务器运行时设置变量的全局值，则当前会话和其他现有会话的值将不受影响。
- MySQL 8.0引入了新的语法SET PERSIST，允许在运行时设置一次值，MySQL将把这个设置写入磁盘，以便在下次重启后继续使用该值。
- 动态设置变量可能会产生意想不到的副作用。在线更改设置时要小心，可能会导致服务器执行大量工作。

## 基本配置

下面是一个最小化的配置文件，基于 MySQL 8.0。虽然看起来配置项不多，但是已经超过了很多人的需要。
```ini
[mysqld]
# GENERAL
datadir = /var/lib/mysql
socket  = /var/lib/mysql/mysql.sock
pid_file= /var/lib/mysql/mysql.pid
user    = mysql
port    = 3306
# INNODB
innodb_buffer_pool_size         = <value>
innodb_log_file_size            = <value>
innodb_file_per_table           = 1
innodb_flush_method             = O_DIRECT
# LOGGING
log_error         = /var/lib/mysql/mysql-error.log
log_slow_queries  = /var/lib/mysql/mysql-slow.log
# OTHER
tmp_table_size    = 32M
max_heap_table_size            = 32M
max_connections   = <value>
thread_cache_size = <value>
table_open_cache  = <value>
open_files_limit  = 65535
[client]
socket  = /var/lib/mysql/mysql.sock
port    = 3306
```

## 内存相关配置

### InnoDB 缓冲池

参考[MySQL中innodb_buffer_pool_size的配置](https://blog.csdn.net/javaanddonet/article/details/109517031)

### 线程缓存

**thread_cache_size**

指定了MySQL可以保存在缓存中的线程数。设置该值的一个好的方法是观察Threads_connected变量，并尝试将thread_cache_size设置得足够大，以处理工作负载中的典型波动。例如，如果Threads_connected通常保持在100到120之间，那么可以将缓存大小设置为20。如果停留在500到700之间，那么将缓存大小设置为200也足够大了。

## I/O 相关配置

InnoDB 的缓冲区和文件
![图5-1：InnoDB的缓冲区和文件](https://s2.loli.net/2024/08/24/AF2TZl3sXHnW7v6.png)

### InnoDB 事务日志

事务在提交是不是直接写到数据表空间的，而是先写入事务日志中，这样做可以将随机I/O转为顺序I/O，减小开销。但是事务日志使用循环缓冲区，当发生环绕时需要将之前的日志刷新到磁盘。

日志文件的总大小由innodb_log_file_size和innodb_log_files_in_group控制。

### 日志缓冲区

InnoDB修改数据时会将修改记录写入日志缓冲区，并将其保存在内存中。当缓冲区满了、事务提交时，或者每秒1次（这三个条件以先满足者为准），InnoDB会将缓冲区刷新到磁盘上的日志文件中。如果有大型事务，增加缓冲区大小（默认为1MB）有助于减少I/O。

**innodb_log_buffer_size**

设置控制缓冲区大小，通常不需要将缓冲区设置得太大。建议的范围是1～8MB，一般来说足够了，除非写入很多大的BLOB记录。

**innodb_flush_log_at_trx_commit**

用来控制日志缓冲区的刷新位置和刷新频率。
- 0: 每秒定时将日志缓冲区写入日志文件，并刷新日志文件，但在事务提交时不做任何操作。
- 1: 每次事务提交时，将日志缓冲区写入日志文件，并将其刷新到持久存储中。这是默认的（也是最安全的）设置；它保证你不会丢失任何已提交的事务，除非磁盘或操作系统“假装”进行刷新操作（没有将数据真正写入磁盘）。
- 2: 每次事务提交时都将日志缓冲区写入日志文件，但不执行刷新。InnoDB按计划每秒刷新1次。与0设置最重要的区别是，如果只是MySQL进程崩溃，设置为2不会丢失任何事务。但是，如果整个服务器崩溃或断电，仍然可能丢失事务。

了解将日志缓冲区写入日志文件和将日志刷新到持久存储之间的区别很重要。在大多数操作系统中，将缓冲区写入日志只是将数据从InnoDB的内存缓冲区移动到操作系统的缓存中，依然还是在内存中。

**innodb_flush_method**

该选项允许配置InnoDB与文件系统的实际交互方式。如果你使用的是类UNIX操作系统，并且RAID控制器有备用电池的写缓存，建议使用O_DIRECT。如果不是，则default或O_DIRECT都可能是最佳选择，具体取决于应用程序。

### InnoDB表空间

**innodb_file_per_table**

该选项允许你将InnoDB配置为每个表使用单独的文件。它将数据存储在数据库目录下的tablename.ibd文件中。这使得删除表时更容易回收空间。然而，将数据放在多个文件中实际上会导致更多的空间浪费，因为跟InnoDB单个表空间中的内部碎片相比，每个.ibd文件中都会有一些浪费的空间。

该选项的缺点（从8.0.23版本开始，这应该不再是一个问题了。）
- 删除表将在文件系统级别解除（删除）文件的链接，这在某些文件系统（ext3）中可能非常慢。
- 删除表空间需要InnoDB在查找属于该表空间的页面时锁定和扫描缓冲池，这在服务器的缓冲池很大时是非常慢的。

最后的建议是使用innodb_file_per_table并限制共享表空间的大小。

如果事务长时间保持打开状态（即使没有做任何工作），并且使用默认的可重复读取事务隔离级别，InnoDB将无法删除行的旧版本，因为未提交的事务仍需要能够看到它们。InnoDB将旧版本存储在表空间中，因此随着更多数据的更新，它将继续增长。相关配置如下。

**innodb_purge_threads**

设置后台清除操作的线程数。

**innodb_purge_batch_size**

设置从历史列表中清除一批解析和处理的undo log页数。

**innodb_max_purge_lag**
- 非0: 在InnoDB开始延迟更多修改数据的查询之前，可以等待清除的最大事务数。

其他 I/O 配置项

**sync_binlog**

选项控制MySQL如何将二进制日志刷新到磁盘，默认值是1，意味着MySQL将执行刷新并保持二进制日志的持久性和安全性。强烈推荐将其设置为1，不建议设置为任何其他值。

## 并发相关配置

旧版本的MySQL（低于5.7）面临许多高并发可伸缩性的挑战。所有的东西都在诸如缓冲池互斥锁之类的全局互斥锁上排队，导致服务器几乎停止运行。如果升级到较新版本的MySQL，在大多数情况下不需要限制并发性。

**innodb_thread_concurrency**

该变量限制了内核中同时可以有多少线程。
- 0表示对线程的数量没有限制。
- 建议设置为与可用CPU核数相同的值，然后根据需要调整大小。

**innodb_thread_sleep_delay**

如果内核中已经有超过允许数量的线程，则新的线程不能进入内核。InnoDB使用一个两阶段的过程来尝试让线程尽可能高效地进入内核。两阶段策略减少了操作系统调度器导致的上下文切换开销。线程首先休眠innodb_thread_sleep_delay指定的微秒数，然后再重试。如果仍然不能进入，它将进入一个等待线程队列，将控制权交给操作系统。

**innodb_concurrency_tickets**

一旦线程进入内核，InnoDB就有一定数量的“门票”，可以“免费”返回内核，而无须任何并发性检查。这限制了它在返回到其他等待的线程队列之前可以完成的工作量。innodb_concurrency_tickets选项控制“门票”的数量。除非有很多非常长时间运行的查询，否则很少需要更改这个选项。“门票”是根据查询而不是事务授予的。一旦查询完成，未使用的门票将被丢弃。

**innodb_commit_concurrency**

该变量控制着可以同时提交的线程数。表示允许同时提交任意数量的事务。

## 安全相关配置

**max_connect_errors**

相当于连接重试次数，超过后服务器将拒绝该客户端进行连接，除非刷新 Host Cache。如果启用了skip_name_resolve，则max_connect_errors选项将无效，因为其行为取决于主机缓存，而主机缓存被skip_name_resolve禁用。

**max_connections**

此设置类似于紧急刹车，以防止服务器被来自应用程序的大量连接压垮。注意观察随时间变化的max_used_connections状态变量。这是一个高水位线，可以显示服务器是否在某个时刻出现了连接高峰。如果到达max_connections，则客户端可能至少被拒绝了一次。

**skip_name_resolve**

当客户端连接服务器时，服务器会进行主机名检查，这需要反向DNS。如果DNS出现问题会出现连接超时。建议关闭该选项。

**sql_mode**

设置服务器SQL模式。模式会影响 MySQL 支持的 SQL 语法及其执行的数据验证检查。

**sysdate_is_now**

确保sysdate和now返回的日期是一样的。

**read_only和super_read_only**

read_only选项可防止未经授权的用户对副本进行更改，副本应仅通过复制而不是从应用程序接收更改。更严格的只读选项super_read_only，它甚至可阻止拥有SUPER权限的用户写入数据。启用此功能后，唯一可以将更改写入数据库的就是复制。

## 高级 InnoDB 配置

**innodb_autoinc_lock_mode**

参考[MySQL innodb_autoinc_lock_mode 详解](https://www.cnblogs.com/JiangLe/p/6362770.html)

**innodb_buffer_pool_instances**

在MySQL 5.5及更新的版本中，此设置将缓冲池划分为多个段，这可能是提高多核机器上MySQL在高并发工作负载下可伸缩性最重要的方法之一。多个缓冲池对工作负载进行分区，这样一些全局互斥体就不会成为争用热点。

**innodb_io_capacity**

参考[MYSQL io_capacity 哥俩，你调了吗？](https://cloud.tencent.com/developer/article/1596411)

**innodb_read_io_threads和innodb_write_io_threads**

这些选项控制有多少后台线程可用于I/O操作。

**innodb_strict_mode**

此设置使InnoDB在某些情况下抛出错误而不是警告，尤其是无效或可能导致危险的CREATE TABLE选项。

**innodb_old_blocks_time**

参考[Innodb存储引擎的几个小知识点](https://cloud.tencent.com/developer/article/1591792)

## 最小资源配置

自己也在低配置的 VPS 上用 Docker 搭建了 MySQL，以下是资源占用最小的配置，MySQL 版本为9.0，刚启动时内存占用150MB。

```ini
[mysqld]
default-time-zone='+08:00'

performance_schema=off

innodb_buffer_pool_size=5M
innodb_log_buffer_size=256K
max_connections=50
key_buffer_size=8
thread_cache_size=1
host_cache_size=0
innodb_ft_cache_size=1600000
innodb_ft_total_cache_size=32000000
table_open_cache=1000

# per thread or per operation settings
thread_stack=131072
sort_buffer_size=32K
read_buffer_size=8192
read_rnd_buffer_size=8192
max_heap_table_size=16K
tmp_table_size=1K
bulk_insert_buffer_size=0
join_buffer_size=128
net_buffer_length=1K
innodb_sort_buffer_size=64K

#settings that relate to the binary log (if enabled)
binlog_cache_size=4K
binlog_stmt_cache_size=4K

innodb_log_file_size=4194304
innodb_flush_log_at_trx_commit=0
innodb_flush_method=O_DIRECT
skip_name_resolve=ON
sync_binlog=0
skip-log-bin
```

MySQL 配置优化

本文是原书第1章的摘抄，大部分概念还是熟悉的，重点还是 InnoDB 本身。



## MySQL 逻辑架构

```mermaid
flowchart TB
	c[客户端] --> conn[连接/线程处理]
	
	subgraph server
	conn --> p[解析器]
	p --> o[优化器]
	end
	
	subgraph storage
	o --> s[存储引擎]
	end
```

连接管理与安全性
- 线程池
- 身份验证
- TLS

优化与执行
- 重写查询
- 表的读取顺序
- 选择合适的索引
- hint
- 从MySQL 5.7.20版本开始，查询缓存已经被官方标注为被弃用的特性，并在8.0版本中被完全移除。

## 并发控制

读写锁
- 共享锁（shared lock）/读锁（read lock）
- 排他锁（exclusive lock）/写锁（write lock）

锁的粒度
- 表锁（table lock）
- 行锁（row lock）
- 元数据锁，用于修改表名或者schema
- 8.0还引入了应用程序级别的锁

## 事务

**原子性（atomicity）**

一个事务必须被视为一个不可分割的工作单元，整个事务中的所有操作要么全部提交成功，要么全部失败回滚。

**一致性（consistency）**

数据库总是从一个一致性状态转换到下一个一致性状态。如果事务最终没有提交，该事务所做的任何修改都不会被保存到数据库中。

**隔离性（isolation）**

通常来说（涉及隔离级别），一个事务所做的修改在最终提交以前，对其他事务是不可见的。

**持久性（durability）**

一旦提交，事务所做的修改就会被永久保存到数据库中。
- 持久性也分很多不同的级别。
- 不可能有100%的持久性保障。

### 隔离级别

**READ UNCOMMITTED（未提交读）**

在READ UNCOMMITTED级别，在事务中可以查看其他事务中还没有提交的修改。这个隔离级别会导致很多问题，从性能上来说，READ UNCOMMITTED不会比其他级别好太多，却缺乏其他级别的很多好处，除非有非常必要的理由，在实际应用中一般很少使用。

读取未提交的数据，也称为脏读（dirty read）。

**READ COMMITTED（提交读）**

READ COMMITTED满足前面提到的隔离性的简单定义：一个事务可以看到其他事务在它开始之后提交的修改，但在该事务提交之前，其所做的任何修改对其他事务都是不可见的。这个级别仍然允许不可重复读（nonrepeatable read），这意味着同一事务中两次执行相同语句，可能会看到不同的数据结果。

大多数数据库系统的默认隔离级别是READ COMMITTED。

**REPEATABLE READ（可重复读）**

REPEATABLE READ解决了READ COMMITTED级别的不可重复读问题，保证了在同一个事务中多次读取相同行数据的结果是一样的。但是理论上，可重复读隔离级别还是无法解决另外一个幻读（phantom read）的问题。

所谓幻读，指的是当某个事务在读取某个范围内的记录时，另外一个事务又在该范围内插入了新的记录，当之前的事务再次读取该范围的记录时，会产生幻行（phantom row）。InnoDB和XtraDB存储引擎通过多版本并发控制（MVCC，Multiversion Concurrency Control）解决了幻读的问题。

REPEATABLE READ是MySQL默认的事务隔离级别。

**SERIALIZABLE（可串行化）**

SERIALIZABLE是最高的隔离级别。该级别通过强制事务按序执行，使不同事务之间不可能产生冲突，从而解决了前面说的幻读问题。简单来说，SERIALIZABLE会在读取的每一行数据上都加锁，所以可能导致大量的超时和锁争用的问题。实际应用中很少用到这个隔离级别，除非需要严格确保数据安全且可以接受并发性能下降的结果。

ANSI SQL 的隔离级别

| 隔离级别             | 脏读  | 不可重复读 | 幻读  | 加锁读 |
| ---------------- | --- | ----- | --- | --- |
| READ UNCOMMITTED | 是   | 是     | 是   | 否   |
| READ COMMITTED   | 否   | 是     | 是   | 否   |
| REPEATABLE READ  | 否   | 否     | 是   | 否   |
| SERIALIZABLE     | 否   | 否     | 否   | 是   |

### 死锁

死锁是指两个或多个事务相互持有和请求相同资源上的锁，产生了循环依赖。当多个事务试图以不同的顺序锁定资源时会导致死锁。当多个事务锁定相同的资源时，也可能会发生死锁。

```sql
-- 事务1
START TRANSACTION;
UPDATE StockPrice 
SET close = 45.50 WHERE stock_id = 4 and date = '2020-05-01';UPDATE StockPrice 
SET close = 19.80 WHERE stock_id = 3 and date = '2020-05-02';COMMIT;

-- 事务2
START TRANSACTION;
UPDATE StockPrice 
SET high = 20.12 WHERE stock_id = 3 and date = '2020-05-02';UPDATE StockPrice 
SET high = 47.20 WHERE stock_id = 4 and date = '2020-05-01';COMMIT;
```

InnoDB 检测到循环依赖后会立即返回错误，或者超过锁等待超时时间限制后直接终止查询（回滚）。应用程序在设计时需要考虑处理死锁，大多数情况下只需要重新从头开始执行被回滚的事务即可。

### 事务日志

事务日志用于提高事务的效率。

存储引擎更新数据的顺序是：
```mermaid
graph LR;
	mem[内存] --> tlog[事务日志] --> hdd[磁盘];
```

存储引擎只需要更改内存中的数据副本，而不用每次修改磁盘中的表，这会非常快。然后再把更改的记录写入事务日志中，事务日志会被持久化保存在硬盘上。

因为事务日志采用的是追加写操作，是在硬盘中一小块区域内的顺序I/O，而不是需要写多个地方的随机I/O，所以写入事务日志是一种相对较快的操作。

最后会有一个后台进程在某个时间去更新硬盘中的表。因此，大多数使用这种技术（write-ahead logging，预写式日志）的存储引擎修改数据最终需要写入磁盘两次。

### AUTOCOMMIT

默认情况下，单个INSERT、UPDATE或DELETE语句会被隐式包装在一个事务中并在执行成功后立即提交，这称为自动提交（AUTOCOMMIT）模式。通过禁用此模式，可以在事务中执行一系列语句，并在结束时执行COMMIT提交事务或ROLLBACK回滚事务。

如果设置了AUTOCOMMIT=0，则当前连接总是会处于某个事务中，直到发出COMMIT或者ROLLBACK，然后MySQL会立即启动一个新的事务。

还有一些命令，当在活动的事务中发出时，会导致MySQL在事务的所有语句执行完毕前提交当前事务。这些通常是进行重大更改的DDL命令，如ALTER TABLE，但LOCK TABLES和其他一些语句也具有同样的效果。

```sql
-- 设置 autocommit
SET SESSION AUTOCOMMIT=0;
SET GLOBAL AUTOCOMMIT=0

-- 设置隔离级别
SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED;
```

### 在事务中混合使用存储引擎

MySQL不在服务器层管理事务，事务是由下层的存储引擎实现的。所以在同一个事务中，混合使用多种存储引擎是不可靠的。

### 隐式锁定和显式锁定

InnoDB使用两阶段锁定协议（two-phase locking protocol）。在事务执行期间，随时都可以获取锁，但锁只有在提交或回滚后才会释放，并且所有的锁会同时释放。前面描述的锁定机制都是隐式的。InnoDB会根据隔离级别自动处理锁。

显示锁定
```sql
SELECT ... FOR SHARE -- MySQL8.0的新语句
-- 取代以前的 SELECT...LOCK IN SHARE MODE
SELECT ... FOR UPDATE
```

MySQL还支持LOCK TABLES和UNLOCK TABLES命令，这些命令在服务器级别而不在存储引擎中实现。建议除了在禁用AUTOCOMMIT的事务中可以使用之外，其他任何时候都不要显式地执行LOCK TABLES，不管使用的是什么存储引擎。

## 多版本并发控制

MySQL 的大多数事务型存储引擎都不是简单的使用行级锁，而是和 MVCC 结合使用。MVCC 的实现机制各不相同。MVCC 可以视为行级锁的变种，开销更低，实现了非阻塞的读操作，写操作也只锁定必要的行。

MVCC的工作原理是使用数据在某个时间点的快照来实现的。MVCC 的实现变体包括乐观并发控制和悲观并发控制

MVCC仅适用于REPEATABLE READ和READ COMMITTED隔离级别。READ UNCOMMITTED与MVCC不兼容，是因为查询不会读取适合其事务版本的行版本，而是不管怎样都读最新版本。SERIALIZABLE与MVCC也不兼容，是因为读取会锁定它们返回的每一行。

## 复制

```mermaid
flowchart TB
	s[源节点] --二进制日志--> r1[副本节点1]
	s --二进制日志--> r2[副本节点2]
```

MySQL提供了一种原生方式来将一个节点执行的写操作分发到其他节点，这被称为复制。对于在生产环境中运行的任何数据，都应该使用复制并至少有三个以上的副本，理想情况下应该分布在不同的地区（在云托管环境中，称为region）用于灾难恢复计划。

多年来，MySQL中的复制变得十分复杂。全局事务标识符、多源复制、副本上的并行复制和半同步复制是一些主要的更新。

## 数据文件结构

在8.0版本中，MySQL将表的元数据重新设计为一种数据字典，包含在表的.ibd文件中。这使得表结构上的信息支持事务和原子级数据定义更改。

在操作期间，我们不再仅仅依赖information_schema来检索表定义和元数据，而是引入了字典对象缓存，减少 I/O。每个表的.ibd和.frm文件被替换为已经被序列化的字典信息（.sdi）。

## InnoDB引擎

InnoDB是MySQL的默认事务型存储引擎，它是为处理大量短期事务而设计的。
- InnoDB将数据存储在一系列的数据文件中，这些文件统被称为表空间（tablespace）。
- InnoDB使用MVCC来实现高并发性，并实现了所有4个SQL标准隔离级别。InnoDB默认为REPEATABLE READ隔离级别。
- 通过间隙锁（next-key locking）策略来防止在这个隔离级别上的幻读：InnoDB不只锁定在查询中涉及的行，还会对索引结构中的间隙进行锁定，以防止幻行被插入。

InnoDB 内部做的优化
- 从磁盘预取数据的可预测性预读
- 能够自动在内存中构建哈希索引以进行快速查找的自适应哈希索引（adaptive hash index）
- 用于加速插入操作的插入缓冲区（insert buffer）

作为事务型存储引擎，InnoDB可以通过一些机制和工具支持真正的在线“热”备份，包括Oracle专有的MySQL Enterprise Backup和开源的Percona XtraBackup。

从MySQL 5.6开始，InnoDB引入了在线DDL，它最初只支持有限的使用场景，但在5.7和8.0版本中引入了就地更改schema机制，允许在不使用完整表锁和外部工具的情况下进行特定的表更改操作，这大大提高了MySQL InnoDB表的可操作性。

### JSON 文档支持

JSON类型在5.7版本被首次引入InnoDB，它实现了JSON文档的自动验证，并优化了存储以允许快速读取。

InnoDB还引入了SQL函数来支持在JSON文档上的丰富操作。MySQL 8.0.7的进一步改进增加了在JSON数组上定义多值索引的能力。将常用访问模式匹配到可以映射JSON文档值的函数这一特性可以进一步加快对JSON类型的读取访问查询。

### 数据字典的变化

MySQL 8.0删除了基于文件的表元数据存储，并将其转移到使用InnoDB表存储的数据字典中。这给所有类似修改表结构这样的操作带来了InnoDB的崩溃恢复事务的好处。

### 原子 DDL

MySQL 8.0引入了原子数据定义更改。这意味着数据定义语句现在要么全部成功完成，要么全部失败回滚。这是通过创建DDL特定的Undo日志和Redo日志来实现的

## 参考

- [17.7 InnoDB Locking and Transaction Model](https://dev.mysql.com/doc/refman/8.4/en/innodb-locking-transaction-model.html)

MySQL 基本概念

我是个 CURD 工程师，属于第五等工程师。



## 什么是工程师文化

先看一些特征

### 地位高

一种职业受人尊敬，人为地强调它的地位高是没有用的，必须要有一种机制保证他们的收入很高，这样最优秀的人才有动力从事相应的工作。

2013年硅谷和美国主要IT公司软件工程师的基本收入与其他行业从业人员收入的对比
![2013年硅谷和美国主要IT公司软件工程师的基本收入与其他行业从业人员收入的对比](https://s2.loli.net/2024/08/17/vPpn5YdgI6KzM4L.png)

### 工作稳定

工程师的工作比较稳定，公司裁员时最后才可能裁撤到工程师。另外，他们的工作时间比较灵活，每年的休假比较多，很多人愿意做一辈子工程师，这使得美国公司里一线工程师的平均工龄比中国公司里同样职位的工程师要长很多，经验也自然更丰富。这一点在硅谷的公司里更加明显。

在硅谷的另一些公司，比如Facebook和苹果里，虽然看上去好的产品经理地位最高，其实他们大多是工程师出身。而在半导体公司，基本上只能让工程师们说了算，因为半导体相关的专业技术非专业人士看不懂，甚至半导体的销售常常也需要由主管工程的副总裁负责。

### Mens et manus

- 一个合格的工程师，必须能够自己动手解决问题，而不是让别人告诉他应该怎么做。
- 一个合格的工程师，至少应该能够独立地实现一项工程目标，不论目标大小。
- 与科学家不同，工程师不关心那些理论的东西，不会在遇到问题时从研究理论做起，也不会站在那里等到某个理论问题解决了之后才开始动手，而是在理论问题还没有解决时，设法绕过去，搞定实际问题。
- 灵活运用现有技术。
- 对新技术有非常强的好奇心，愿意把新技术运用到现有产品中。

改变世界的技术和最初发明的地点

| 以为是来自硅谷的发明 | 实际发明地点 |
| --- | --- |
|晶体管|贝尔实验室（新泽西）|
|计算机|宾夕法尼亚大学|
|机器人|英国|
|人工智能|美国东部大学（在达特茅斯提出，MIT 最初实现）|
|程序语言|英国|
|数据库|IBM 等|
|计算机游戏|MIT|
|游戏机|新罕布什尔|
|互联网|美国政府ARPA|
|PC|好利获得公司（即Olivetti，意大利）|
|WWW|欧洲核子中心（CERN）|
|搜索引擎|欧洲核子中心以及美国加州以外几所大学|
|社交网络|纽约|
|智能手机|日本Docomo（NTT的移动子公司）|
|电子邮件|MIT|
|可穿戴式计算机|MIT|
|太空技术|德国、苏联、美国的得克萨斯和洛杉矶等地|
|电动汽车|早期版本：爱迪生GE（纽约）；当代版原型：GM（底特律）|
|无人驾驶汽车|卡内基–梅隆大学|
|虚拟现实（VR）|MIT|

### 会动脑

硅谷工程师文化另一个重要特点是不仅要会动手，更要会动脑。

在很多公司，产品经理和工程师是两个独立的角色。在中国的一些互联网公司里，有着大量的产品经理，在个别项目上产品经理甚至比工程师还多。这样的搭配带来了两个方面的恶果，首先很多产品经理不得不去做那些本不该由他们来完成的细节设计，同时本该参与产品设计的工程师在设计上完全懒得动脑思考。

另外，产品经理可能会因为缺乏对工程技术的了解而提出不合理的要求，而工程师也会因为缺乏对产品的全面了解，做的东西达不到产品经理预想的要求。在硅谷的公司里，产品经理和工程师的比例非常低，在Google这样的公司或者半导体公司里，这个比例可能是1：20，甚至比1：100还低。

### 区别对待不同水平的工程师

苏联著名物理学家朗道（Lev Landau，1908—1968）提出的朗道等级能够比较清晰的解释工程师之间的差别。

工程师的五个等级
![工程师的五个等级](https://s2.loli.net/2024/08/17/7TbYWvsHuqO58PF.png)

第五等工程师，能够独立设计和实现一项功能的人。这是对工程师的基本要求，如果一个人只是懂一点工程实现的手段，需要别人告诉他怎么做，那最多算是助理工程师或者技工，不在我们讨论的工程师之列。

第四等的工程师就需要有点产品头脑，他们在做一件事之前，要知道所做出来的东西是否有用、易用，是否便于维护，是否性能稳定，等等。除了要具备产品设计方面的基本知识，还要具有一定的领导才能，能在整个产品的生命周期从头到尾将一个产品负责到底。这在很多硅谷的公司里，基本上是一个高级工程师所应有的基本素质。

第三等的工程师，可以做出行业里最好的产品。他们与第四等工程师有着质的差别，这不仅反映在技术水平、对市场的了解、对用户心理的了解以及组织能力等诸方面，而且也反映在悟性的差异上。

第二等的工程师是那些可以给世界带来惊喜的人。他们与第三四五等工程师的差别在于其工作的原创性以及对世界的影响力。当然，他们的工作不是科学研究，这一点和科学家毕竟不同。

第一等的工程师是开创一个全新行业的人。这些工程师不仅在技术和产品等各个方向上与第二等的工程师有了质的差别，而且在经验和管理上也是好手，他们通常也是企业家，并通过自己的产品改变了世界。

### 全社会对工程师的认可

这种认可不仅包括对工程师的尊重，以及给予他们较高的社会地位，还包括允许不同等级的工程师在收入上有巨大差异。如果拉大收入差距能够最大程度地发展生产力，而平均主义不能，那么采用前一种分配方式的地区无疑会获得更快的发展，硅谷就是这样的地区。

在硅谷的很多公司内部，不同层级、不同贡献的工程师之间，工资和奖金的差异其实不大，但是期权起到了调节他们收入的主要作用。这使得第二等工程师的收入真的可以比第三等工程师多出一个数量级，而第三等和第四等之间，收入可能也有数量级之差。

### 工程师文化的明确定义

简单地讲，工程师文化有两层含义，首先在于，它强调了一个机构或者一个社会以工程师为核心创造未来的价值。接下来，既然工程师是创造价值的核心，那么他们必须具有主动性，不断承担越来越多的使命。由于人的能力有大有小，贡献会有巨大的差距，这样也会直接导致他们的收入有巨大差距。只有正视这种差距，接受这种差距，才是信息时代应该有的思维。

## 硅谷工程师文化的形成原因

从历史上讲，欧美国家在历史上很少有大一统的帝国，官员的重要性就要小得多，专业人士的地位相对比较高。世界上很多国家和地区对工程师远比中国尊重和重视。

硅谷工程师文化也有它本身的成因，主要是公司所有权和分配制度与其他地方有所不同。员工特别是核心员工和公司都是一种契约关系，因此行政职务和汇报关系就不是那么重要了，但是这一点在中国目前还做不到。

## 参考

- [什么是工程师文化？](https://coolshell.cn/articles/17497.html)
- [Programmer's Day](https://en.wikipedia.org/wiki/Programmer%27s_Day)
- [33 | Facebook企业文化：工程师文化是创造力引擎](https://time.geekbang.org/column/article/162869)

工程师文化

ChatGPT 教我防 DDoS

美国汽车工业界将汽车按照自动驾驶的程度分为6级。



-  第0级，完全由人来驾驶的汽车，今天市场上99%以上的汽车都属于这一种。
- 第1级，具有能控制方向的辅助驾驶功能。比如今天的特斯拉汽车就属于这一类。
- 第2级，由人监控的自动驾驶汽车。这种汽车大部分时候已经是自动驾驶了，但是依然保留了人工干预的功能，百度路上实验的汽车属于这一种。事实上，这种车在高速公路的进出口、闹市区，还完全需要由人控制，否则既不安全，也对自己和他人不负责任。
- 第3级，限定条件的无人驾驶汽车。比如限定在高速公路上，但是不允许在闹市区自动行驶。或者在一个园区内使用，或者限定从住宅小区到地铁站专线运行。当然，限制也可以是在时间上，比如限制只能在晚上9点到第二天清晨6点上路。
- 第4级，高度自动的无人驾驶汽车。它可以没有路段的限制，但是会被要求在夜晚或者交通流量比较少的时间使用。
- 第5级，完全的无人驾驶。

参考
- [Self-driving car](https://en.wikipedia.org/wiki/Self-driving_car)