一、数据字典与原子DDL
mysql的所有表结构定义的元数据存放在mysql.idb中。整合了存储有关数据库对象信息的事务数据字典，所有的元数据都用InnoDB引擎进行存储.看下图，我创建了一个 database business,你会发现表的定义文件*.frm没有了。

[ root @ yw - gz - hd - test - 211 mysql ] # ls
auto . cnf binlog . index client - cert . pem ibdata1 mysql public_key . pem undo_001
binlog . 000001 business client - key . pem ib_logfile0 mysql . ibd server - cert . pem undo_002
binlog . 000002 ca - key . pem error . log ib_logfile1 performance_schema server - key . pem yw - gz - hd - test - 211 . pid
binlog . 000003 ca . pem ib_buffer_pool ibtmp1 private_key . pem sys
[ root @ yw - gz - hd - test - 211 mysql ] # ls business /
job_execution_log . ibd t_gw_remit_query . ibd t_mer_transfer . ibd
job_status_trace_log . ibd t_gw_remit_serial . ibd t_sms_gateway . ibd
t_bal_sett_report . ibd t_gw_serial . ibd t_sms_recode . ibd
t_boss_logger . ibd t_mail_record . ibd t_sms_service . ibd

在执行DDL之类的操作时，很难做到crash-safe，更别说让DDL具备事务性了。

在MySQL8.0之前，DDL操作在server crash的情况下，会遗留.frm,.ibd文件。MySQL8.0 能实现原?DDL（包括 DROP TABLE, DROP SCHEMA, CREATE TABLE, TRUNCATE TABLE, ALTER TABLE），在server crash的情况下，不会遗留.frm，.ibd临时文件，保证了DDL操作的原子性！

二、字符集支持（Character set support）
数据库的默认字符集 latin1 到 utf8mb4 。

三、重构sql分析器,提升性能
改进SQL分析器。旧的分析器由于其语法复杂性和自顶向下的分析方式从而有严重的限制，导致难以维护和扩展。

四、onlineDDL 的巨大改进。8.0.12版本将会增加 ALGORITHM=INSTANT 方法。我们知道，mysql的对表结构的更改，一直让DBA头疼。目前有2两种ALGORITHM [=] {INPLACE|COPY} 。instant是比inplace方法更改，锁定表的时间更短。

五、innodb 增强，提升性能
(1)innodb_undo_tablespaces的最小值为2，并且不再允许将innodb_undo_tablespaces设置为0。最小值2确保回滚段始终在撤消表空间中创建，而不是在系统表空间中创建
(2)InnoDB临时表都将在共享临时表空间ibtmp1中创建

六、调整back_log的默认值，保持和 max_connections一致，增强突发流量带来的连接处理容量。这告诉我们，有些参数是随着另外一个参数动态调整的。
新增innodb_dedicated_server，让InnoDB根据服务器上检测到的内存量自动配置innodb_buffer_pool_size，innodb_log_file_size，innodb_flush_method

原来是：来试验一下：
mysql > select * from `performance_schema` . global_variables where VARIABLE_NAME in ( 'innodb_dedicated_server' , 'innodb_buffer_pool_size' , 'innodb_buffer_pool_instances' ) ;
+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + - - - - - - - - - - - - - - - - +
| VARIABLE_NAME | VARIABLE_VALUE |
+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + - - - - - - - - - - - - - - - - +
| innodb_buffer_pool_instances | 1 |
| innodb_buffer_pool_size | 134450944 |
| innodb_dedicated_server | OFF |
+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + - - - - - - - - - - - - - - - - +
3 rows in set ( . 00 sec )
后来是
mysql > select * from `performance_schema` . global_variables where VARIABLE_NAME in ( 'innodb_dedicated_server' , 'innodb_buffer_pool_size' , 'innodb_buffer_pool_instances' ) ;
+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + - - - - - - - - - - - - - - - - +
| VARIABLE_NAME | VARIABLE_VALUE |
+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + - - - - - - - - - - - - - - - - +
| innodb_buffer_pool_instances | 8 |
| innodb_buffer_pool_size | 6442450944 |
| innodb_dedicated_server | ON |
+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + - - - - - - - - - - - - - - - - +
3 rows in set ( . 00 sec )

七、在线修改系统变量后，会将修改后的值持久化到磁盘。他并不是持久化到my.cnf中，而且重新生成一个新的文件mysqld-auto.cnf，并将修改后的值保存到该文件中。 mysqld-auto.cnf文件中的配置相比my.cnf文件具有高优先级，如果相同配置出现在两个文件中，就以mysqld-auto.cnf文件中的记录为主。

mysql > set persist autocommit = 1 ;
Query OK , 0 rows affected ( . 00 sec )
mysql >

八、对于开发人员来说，增加了窗口函数，with 语法，对于编写复杂的sql语句提供了强有力的支撑

九、InnoDB性能提升

废除buffer pool mutex,将原来一个mutex拆分成多个，提高并发

MySQL 8.0 版本开始支持期待已久直方图。优化器会利用column_statistics的数据，判断字段的值的分布，得到更准确的执行计划。
这些有很多的关于性能提升的数据，最后，我将用压力测试工具来实际压测一下，看看oracle公司有没有撒谎。
下面这些可能会比较长，慢慢压测：
(1)安装sysbench 1.0.9 ,自己百度，不是本章重点
(2)压测怎么少得了监控呢，按照PMM ，自己百度怎么安装。
(3)先做准备工作，看下机器环境：
普通的DELL 服务器R730 SAS 10K 。上面安装的vmware ,分配的一台普通的虚拟机。操作系统: redhat7,4核8G内存，是不是很普通的一台机器呢？相当普通的一台机器

[root@yw-gz-hd-test-211 mysql]# uname -a
Linux yw-gz-hd-test-211 3.10.0-693.el7.x86_64 #1 SMP Tue Aug 22 21:09:27 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
[root@yw-gz-hd-test-211 mysql]# free -m
total used free shared buff/cache available
Mem: 7680 4107 131 8 3441 3242
Swap: 0 0 0
processor : 3
vendor_id : GenuineIntel
cpu family : 6
model : 79
model name : Intel(R) Xeon(R) CPU E5-2640 v4 @ 2.40GHz
stepping : 1
microcode : 0xb000021
cpu MHz : 2399.318
cache size : 25600 KB
physical id : 6
siblings : 1
core id : 0
cpu cores : 1
apicid : 6
initial apicid : 6
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts mmx fxsr sse sse2 ss syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts nopl xtopology tsc_reliable nonstop_tsc eagerfpu pni pclmulqdq ssse3 fma cx16 pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand hypervisor lahf_lm abm 3dnowprefetch fsgsbase tsc_adjust bmi1 hle avx2 smep bmi2 invpcid rtm rdseed adx smap xsaveopt arat
bogomips : 4799.99
clflush size : 64
cache_alignment : 64
address sizes : 43 bits physical, 48 bits virtual
power management:

(4)来看下我们压测的mysql

[root@yw-gz-hd-test-211 ~]# mysql -uroot -p123456
mysql: [Warning] Using a password on the command line interface can be insecure.
Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 218
Server version: 8.0.11 Source distribution
Copyright (c) 2000, 2018, Oracle and/or its affiliates. All rights reserved.
Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.
Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.
mysql> select version();
+-----------+
| version() |
+-----------+
| 8.0.11 |
+-----------+
1 row in set (0.00 sec)

(5)进行数据准备。我们使用默认安装的默认参数。这次压测的数据量是这样的：10个表，每个表500万数据，每个表有1.2G大小。这样的数据量，针对一个中等规模的应用，很典型了。然后，压测有增删改查，比例是这样的：

[root@yw-gz-hd-test-211 ~]# sysbench /usr/share/sysbench/oltp_read_write.lua --db-driver=mysql --mysql-host=127.0.0.1 --mysql-port=3306 --mysql-db=sbtest --mysql-user=root --mysql-password=123456 --table_size=5000000 --tables=10 --threads=30 --time=60 --report-interval=30 prepare
sysbench 1.0.9 (using system LuaJIT 2.0.4)
Initializing worker threads...
Creating table 'sbtest3'...
Creating table 'sbtest8'...
Creating table 'sbtest2'...
Creating table 'sbtest6'...
Creating table 'sbtest7'...
Creating table 'sbtest1'...
Creating table 'sbtest4'...
Creating table 'sbtest10'...
Creating table 'sbtest9'...
Creating table 'sbtest5'...
Inserting 5000000 records into 'sbtest9'
Inserting 5000000 records into 'sbtest2'
Inserting 5000000 records into 'sbtest6'
Inserting 5000000 records into 'sbtest10'
Inserting 5000000 records into 'sbtest8'
Inserting 5000000 records into 'sbtest3'
Inserting 5000000 records into 'sbtest1'
Inserting 5000000 records into 'sbtest7'
Inserting 5000000 records into 'sbtest4'
Inserting 5000000 records into 'sbtest5'
Creating a secondary index on 'sbtest7'...
Creating a secondary index on 'sbtest2'...
Creating a secondary index on 'sbtest1'...
Creating a secondary index on 'sbtest9'...
Creating a secondary index on 'sbtest6'...
Creating a secondary index on 'sbtest4'...
Creating a secondary index on 'sbtest8'...
Creating a secondary index on 'sbtest3'...
Creating a secondary index on 'sbtest5'...
Creating a secondary index on 'sbtest10'...

现在每个表有500万数据，插入还挺快的，我们来看看linux的具体容量有多少？

[root@yw-gz-hd-test-211 mysql]# ls
auto.cnf business ibtmp1 server-cert.pem yw-gz-hd-test-211-bin.000006
binlog.000001 ca-key.pem mysql server-key.pem yw-gz-hd-test-211-bin.000007
binlog.000002 ca.pem mysqld-auto.cnf sys yw-gz-hd-test-211-bin.000008
binlog.000003 client-cert.pem mysql.ibd undo_001 yw-gz-hd-test-211-bin.000009
binlog.000004 client-key.pem off.000001 undo_002 yw-gz-hd-test-211-bin.index
binlog.000005 error.log off.index yw-gz-hd-test-211-bin.000001 yw-gz-hd-test-211.err
binlog.000006 ib_buffer_pool performance_schema yw-gz-hd-test-211-bin.000002 yw-gz-hd-test-211.log
binlog.000007 ibdata1 private_key.pem yw-gz-hd-test-211-bin.000003 yw-gz-hd-test-211.pid
binlog.000008 ib_logfile0 public_key.pem yw-gz-hd-test-211-bin.000004 yw-gz-hd-test-211-slow.log
binlog.index ib_logfile1 sbtest yw-gz-hd-test-211-bin.000005
[root@yw-gz-hd-test-211 mysql]# ls sbtest/ -lh
total 12G
-rw-r----- 1 mysql mysql 1.2G Jul 4 17:53 sbtest10.ibd
-rw-r----- 1 mysql mysql 1.2G Jul 4 17:53 sbtest1.ibd
-rw-r----- 1 mysql mysql 1.2G Jul 4 17:53 sbtest2.ibd
-rw-r----- 1 mysql mysql 1.2G Jul 4 17:53 sbtest3.ibd
-rw-r----- 1 mysql mysql 1.2G Jul 4 17:53 sbtest4.ibd
-rw-r----- 1 mysql mysql 1.2G Jul 4 17:53 sbtest5.ibd
-rw-r----- 1 mysql mysql 1.2G Jul 4 17:53 sbtest6.ibd
-rw-r----- 1 mysql mysql 1.2G Jul 4 17:53 sbtest7.ibd
-rw-r----- 1 mysql mysql 1.2G Jul 4 17:53 sbtest8.ibd
-rw-r----- 1 mysql mysql 1.2G Jul 4 17:53 sbtest9.ibd
[root@yw-gz-hd-test-211 mysql]#

(6)来看看一个压测实例：针对每个表有500万，总共10个表，12G表的库进行压力测试。并发是30个，压测时间180秒。中间没有报错，结果是220TPS，4414QPS

[root@yw-gz-hd-test-211 ~]# sysbench /usr/share/sysbench/oltp_read_write.lua --db-driver=mysql --mysql-host=127.0.0.1 --mysql-port=3306 --mysql-db=sbtest --mysql-user=root --mysql-password=123456 --table_size=5000000 --tables=10 --threads=30 --time=180 --report-interval=30 run
sysbench 1.0.9 (using system LuaJIT 2.0.4)
Running the test with following options:
Number of threads: 30
Report intermediate results every 30 second(s)
Initializing random number generator from current time
Initializing worker threads...
Threads started!
[ 30s ] thds: 30 tps: 242.74 qps: 4868.63 (r/w/o: 3410.06/972.09/486.48) lat (ms,95%): 369.77 err/s: 0.00 reconn/s: 0.00
[ 60s ] thds: 30 tps: 190.53 qps: 3806.64 (r/w/o: 2664.48/761.11/381.05) lat (ms,95%): 511.33 err/s: 0.00 reconn/s: 0.00
[ 90s ] thds: 30 tps: 203.30 qps: 4069.36 (r/w/o: 2848.13/814.63/406.60) lat (ms,95%): 520.62 err/s: 0.00 reconn/s: 0.00
[ 120s ] thds: 30 tps: 229.20 qps: 4579.97 (r/w/o: 3206.27/915.33/458.37) lat (ms,95%): 450.77 err/s: 0.00 reconn/s: 0.00
[ 150s ] thds: 30 tps: 234.27 qps: 4690.00 (r/w/o: 3283.63/937.80/468.57) lat (ms,95%): 475.79 err/s: 0.00 reconn/s: 0.00
[ 180s ] thds: 30 tps: 224.33 qps: 4486.21 (r/w/o: 3139.37/898.17/448.67) lat (ms,95%): 450.77 err/s: 0.00 reconn/s: 0.00
SQL statistics:
queries performed:
read: 556682
write: 159052
other: 79526
total: 795260
transactions: 39763 (220.74 per sec.)
queries: 795260 (4414.71 per sec.)
ignored errors: 0 (0.00 per sec.)
reconnects: 0 (0.00 per sec.)
General statistics:
total time: 180.1368s
total number of events: 39763
Latency (ms):
min: 2.49
avg: 135.89
max: 3105.54
95th percentile: 467.30
sum: 5403557.06
Threads fairness:
events (avg/stddev): 1325.4333/34.79
execution time (avg/stddev): 180.1186/0.00

来看下mysql指标分析图：

可以看到我压测类型是OLTP,实际模拟一个实时交易系统，读写分配比还是很合理。看到慢查询这个图表，没有慢查询语句。MySQL的 query 其中一个点5.64K，就是5640QPS，因为这个是瞬时的，上面4414QPS是平均值，表明合理的。看CPU使用率，有63%是IOwait，说明，瓶颈在磁盘的IO上面。这个结果是符合我的认知的：OLTP交易系统，最后的压力瓶颈应该压测到接近100%cpu，瓶颈都在IO上。

(7)现在还没有对MySQL的参数做调整。之前安装是默认参数，我现在对mysql参数调整一下，达到最优。再次压测，看看有什么情况。
看看调整了什么参数

[root@yw-gz-hd-test-211 ~]# cat /etc/my.cnf
[mysqld]
datadir=/data/mysql
basedir=/usr/local/mysql
log_error=/data/mysql/error.log
log_bin=on
innodb_dedicated_server=on
innodb_log_files_in_group=4
innodb_log_file_size=128024024
innodb_flush_log_at_trx_commit = 0
innodb_doublewrite=off
sync_binlog=0

看看压测的结果是怎么样的？除了默认参数外，这次与上次不同的，还包括并发线程达到100，100并发，可以代表大部分的系统了，很多系统都难以达到100的并发。11221QPS,561TPS ,挺高的。没有错误，没有慢查询语句。

[root@yw-gz-hd-test-211 ~]# sysbench /usr/share/sysbench/oltp_read_write.lua --db-driver=mysql --mysql-host=127.0.0.1 --mysql-port=3306 --mysql-db=sbtest --mysql-user=root --mysql-password=123456 --table_size=5000000 --tables=10 --threads=100 --time=240 --report-interval=30 run
sysbench 1.0.9 (using system LuaJIT 2.0.4)
Running the test with following options:
Number of threads: 100
Report intermediate results every 30 second(s)
Initializing random number generator from current time
Initializing worker threads...
Threads started!
[ 30s ] thds: 100 tps: 184.04 qps: 3726.98 (r/w/o: 2616.03/739.57/371.39) lat (ms,95%): 1129.24 err/s: 0.00 reconn/s: 0.00
[ 60s ] thds: 100 tps: 268.07 qps: 5357.60 (r/w/o: 3750.52/1070.87/536.20) lat (ms,95%): 846.57 err/s: 0.03 reconn/s: 0.00
[ 90s ] thds: 100 tps: 341.60 qps: 6826.82 (r/w/o: 4777.66/1365.96/683.20) lat (ms,95%): 634.66 err/s: 0.00 reconn/s: 0.00
[ 120s ] thds: 100 tps: 432.73 qps: 8658.56 (r/w/o: 6061.32/1731.77/865.47) lat (ms,95%): 580.02 err/s: 0.00 reconn/s: 0.00
[ 150s ] thds: 100 tps: 666.30 qps: 13328.01 (r/w/o: 9330.47/2664.90/1332.63) lat (ms,95%): 450.77 err/s: 0.03 reconn/s: 0.00
[ 180s ] thds: 100 tps: 715.60 qps: 14305.50 (r/w/o: 10012.73/2861.73/1431.03) lat (ms,95%): 493.24 err/s: 0.00 reconn/s: 0.00
[ 210s ] thds: 100 tps: 959.03 qps: 19196.02 (r/w/o: 13440.09/3837.70/1918.23) lat (ms,95%): 363.18 err/s: 0.03 reconn/s: 0.00
[ 240s ] thds: 100 tps: 925.33 qps: 18494.54 (r/w/o: 12944.08/3699.73/1850.73) lat (ms,95%): 397.39 err/s: 0.07 reconn/s: 0.00
SQL statistics:
queries performed:
read: 1888404
write: 539528
other: 269767
total: 2697699
transactions: 134881 (561.05 per sec.)
queries: 2697699 (11221.35 per sec.)
ignored errors: 5 (0.02 per sec.)
reconnects: 0 (0.00 per sec.)
General statistics:
total time: 240.4059s
total number of events: 134881
Latency (ms):
min: 2.24
avg: 178.05
max: 2380.67
95th percentile: 569.67
sum: 24015703.52
Threads fairness:
events (avg/stddev): 1348.8100/30.06
execution time (avg/stddev): 240.1570/0.12

开看下PMM都监控到一些什么吧，看看能不能发现什么东东？

把这台机器的内存，cpu，io，全部榨干了。哈哈，小伙伴们，还满意吧。mysql8的性能还是挺棒的吧
(8)修改一下参数，调整为安全不丢日志情况看看

[ root@yw - gz - hd - test - 211 ~ ] # sysbench /usr/share/sysbench/oltp_read_write . lua - - db - driver = mysql - - mysql - host = 127 . . . 1 - - mysql - port = 3306 - - mysql - db = sbtest - - mysql - user = root - - mysql - password = 123456 - - table_size = 5000000 - - tables = 10 - - threads = 100 - - time = 240 - - report - interval = 30 run
sysbench 1 . . 9 ( using system LuaJIT 2 . . 4 )
Running the test with following options :
Number of threads : 100
Report intermediate results every 30 second ( s )
Initializing random number generator from current time
Initializing worker threads . . .
Threads
[ 30s ] thds : 100 tps : 339 . 12 qps : 6824 . 43 ( r/w/o : 4783 . 19/1359 . 66/681 . 58 ) lat ( ms , 95% ) : 634 . 66 err/s : 0 . 00 reconn/s : 0 . 00
[ 60s ] thds : 100 tps : 336 . 27 qps : 6719 . 18 ( r/w/o : 4703 . 30/1343 . 34/672 . 54 ) lat ( ms , 95% ) : 719 . 92 err/s : 0 . 00 reconn/s : 0 . 00
[ 90s ] thds : 100 tps : 379 . 73 qps : 7588 . 50 ( r/w/o : 5310 . 87/1518 . 17/759 . 47 ) lat ( ms , 95% ) : 733 . 00 err/s : 0 . 00 reconn/s : 0 . 00
[ 120s ] thds : 100 tps : 441 . 00 qps : 8829 . 76 ( r/w/o : 6181 . 63/1766 . 13/882 . 00 ) lat ( ms , 95% ) : 669 . 89 err/s : 0 . 00 reconn/s : 0 . 00
[ 150s ] thds : 100 tps : 575 . 47 qps : 11504 . 53 ( r/w/o : 8053 . 43/2300 . 17/1150 . 93 ) lat ( ms , 95% ) : 559 . 50 err/s : 0 . 00 reconn/s : 0 . 00
[ 180s ] thds : 100 tps : 615 . 27 qps : 12324 . 57 ( r/w/o : 8625 . 83/2468 . 17/1230 . 57 ) lat ( ms , 95% ) : 559 . 50 err/s : 0 . 03 reconn/s : 0 . 00
[ 210s ] thds : 100 tps : 597 . 20 qps : 11932 . 95 ( r/w/o : 8352 . 48/2386 . 08/1194 . 39 ) lat ( ms , 95% ) : 569 . 67 err/s : 0 . 00 reconn/s : 0 . 00
[ 240s ] thds : 100 tps : 526 . 13 qps : 10532 . 39 ( r/w/o : 7372 . 82/2107 . 31/1052 . 27 ) lat ( ms , 95% ) : 559 . 50 err/s : 0 . 00 reconn/s : 0 . 00
SQL statistics :
queries performed :
read : 1601712
write : 457629
other : 228815
total : 2288156
transactions : 114407 ( 475 . 15 per sec . )
queries : 2288156 ( 9503 . 14 per sec . )
ignored errors : 1 ( . 00 per sec . )
reconnects : 0 ( . 00 per sec . )
General statistics :
total time : 240 . 7771s
total number of events : 114407
Latency ( ms ) :
min : 2 . 54
avg : 209 . 93
max : 2692 . 90
95th percentile : 623 . 33
sum : 24017634 . 15
Threads fairness :
events ( avg/stddev ) : 1144 . 0700/28 . 43
execution time ( avg/stddev ) : 240 . 1763/0 . 13

稍微降低。还是很棒，

transactions : 114407 ( 475 . 15 per sec . )
queries : 2288156 ( 9503 . 14 per sec . )

(9)现在我把数据增加

(10)看下测试情况，当我把每个表是数据加到1000万，总共1个亿，线程加到300的时候，实例跑了90秒后，崩溃重启了。日志没有打印出来任何消息，只是mysqld进行了崩溃恢复。

[root@yw-gz-hd-test-211 ~]# sysbench /usr/share/sysbench/oltp_read_write.lua --db-driver=mysql --mysql-host=127.0.0.1 --mysql-port=3306 --mysql-db=sbtest --mysql-user=root --mysql-password=123456 --table_size=10000000 --tables=10 --threads=300  --time=240 --report-interval=30 run
sysbench 1.0.9 (using system LuaJIT 2.0.4)
Running the test with following options:
Number of threads: 300
Report intermediate results every 30 second(s)
Initializing random number generator from current time
Initializing worker threads...
Threads started!
[ 30s ] thds: 300 tps: 233.38 qps: 4806.66 (r/w/o: 3384.19/945.78/476.68) lat (ms,95%): 2320.55 err/s: 0.00 reconn/s: 0.00
[ 60s ] thds: 300 tps: 309.72 qps: 6180.75 (r/w/o: 4326.78/1234.53/619.44) lat (ms,95%): 2009.23 err/s: 0.00 reconn/s: 0.00
[ 90s ] thds: 300 tps: 333.04 qps: 6635.99 (r/w/o: 4637.82/1332.09/666.08) lat (ms,95%): 2238.47 err/s: 0.00 reconn/s: 0.00
/usr/local/mysql/bin/mysqld_safe: line 199:  1865 Killed                  env MYSQLD_PARENT_PID=32055 env MYSQLD_PARENT_PID=32055 env MYSQLD_PARENT_PID=32055 nohup /usr/local/mysql/bin/mysqld --basedir=/usr/local/mysql --datadir=/data/mysql --plugin-dir=/usr/local/mysql/lib/plugin --user=mysql --log-error=/data/mysql/error.log --pid-file=/data/mysql/yw-gz-hd-test-211.pid --socket=/data/mysql/mysql.sock < /dev/null > /dev/null 2>&1 > /dev/null 2>&1 > /dev/null 2>&1

看下日志错误

2018-07-17T09:06:23.211339Z 0 [System] [MY-010931] [Server] /usr/local/mysql/bin/mysqld: ready for connections. Version: '8.0.11'  socket: '/data/mysql/mysql.sock'  port: 3306  Source distribution.
2018-07-17T09:23:54.585049Z 0 [System] [MY-010116] [Server] /usr/local/mysql/bin/mysqld (mysqld 8.0.11) starting as process 1865
^[[B2018-07-17T09:26:19.578094Z 0 [System] [MY-010229] [Server] Starting crash recovery...
2018-07-17T09:26:19.606981Z 0 [System] [MY-010232] [Server] Crash recovery finished.
2018-07-17T09:26:20.127240Z 0 [Warning] [MY-010068] [Server] CA certificate ca.pem is self signed.
2018-07-17T09:26:20.319641Z 0 [System] [MY-010931] [Server] /usr/local/mysql/bin/mysqld: ready for connections. Version: '8.0.11'  socket: '/data/mysql/mysql.sock'  port: 3306  Source distribution.

(11)
(12)
(13)
总结：压力测试告一段落。总结我对mysql8的看法：我最看重的是，mysql8 onlineDDL 的瞬时修改(8.0.12才有),对优化器的重构，with 和窗口函数功能。这些都是巨大提升。稳定性有待提高。

ITPub博客

mysql8.0.11新特性测试

最新文章