存在数据中以 authentication_string 替代 password
连接MySQL
1 TCP/IP
远程连接 mysql -h(host) -u (user) -p
2 命名管道和共享内存
windows中
3 Unix域套接字
非网络协议
socket中寻找套接字文件路径(socket = /usr/……/mysql.sock)
mysql -u(user) -p(password) -S -/usr/……/mysql.sockInnodB存储引擎
概述
特点：第一个完整支持ACID事物的MySQL存储引擎
原子性
整个事务中的所有操作，要么全部完成，要么全部不完成，不可能停滞在中间某个环节。事务在执行过程中发生错误，会被
回滚(Rollback)到事务开始前的状态，就像这个事务从来没有执行过一样。
一致性
一个事务可以封装状态改变(除非它是一个只读的)。事务必须始终保持系统处于一致的状态，不管在任何给定的时间
并发事务有多少。
也就是说：如果事务是
并发多个，系统也必须如同串行事务一样操作。其主要特征是保护性和不变性(Preserving an Invariant)，以转账
案例为例，假设有五个账户，每个账户余额是100元，那么五个账户总额是500元，如果在这个5个账户之间同时发生多个转账，无论
并发多少个，比如在A与B账户之间转账5元，在C与D账户之间转账10元，在B与E之间转账15元，五个账户总额也应该还是500元，这就是保护性和不变性。
隔离性
隔离状态执行事务，使它们好像是系统在给定时间内执行的唯一操作。如果有两个事务，运行在相同的时间内，执行相同的功能，事务的隔离性将确保每一事务在系统中认为只有该事务在使用系统。这种属性有时称为
串行化，为了防止事务操作间的混淆，必须串行化或序列化请求，使得在同一时间仅有一个请求用于同一数据。
持久性
在事务完成以后，该事务对数据库所作的更改便持久的保存在数据库之中，并不会被回滚。
由于一项操作通常会包含许多子操作，而这些子操作可能会因为硬件的损坏或其他因素产生问题，要正确实现ACID并不容易。ACID建议数据库将所有需要更新以及修改的资料一次操作完毕，但实际上并不可行。
目前主要有两种方式实现ACID：第一种是Write ahead logging，也就是日志式的方式(现代数据库均基于这种方式)。第二种是Shadow paging。
相对于WAL(write ahead logging)技术，shadow paging技术实现起来比较简单，消除了写日志记录的开销恢复的速度也快(不需要redo和undo)。shadow paging的缺点就是事务提交时要输出多个块，这使得提交的开销很大，而且以块为单位，很难应用到允许多个事务并发执行的情况——这是它致命的缺点。
WAL 的中心思想是对数据文件 的修改(它们是表和索引的载体)必须是只能发生在这些修改已经 记录了日志之后 -- 也就是说，在日志记录冲刷到永久存储器之后． 如果我们遵循这个过程，那么我们就不需要在每次事务提交的时候 都把数据页冲刷到磁盘，因为我们知道在出现崩溃的情况下， 我们可以用日志来恢复数据库：任何尚未附加到数据页的记录 都将先从日志记录中重做(这叫向前滚动恢复，也叫做 REDO) 然后那些未提交的事务做的修改将被从数据页中删除 (这叫向后滚动恢复 - UNDO)。
行锁设计，支持MVCC，提供一致性非锁定读
被设计用来最有效地利用内存和CPU
体系架构
后台线程：
刷新数据，保证缓冲池中是最新的数据，将已修改数据刷新到磁盘文件，保证数据库发生异常后InnoDB能恢复正常运行状态
默认情况下：4个IO thread 、1个master thread、1个锁(lock)监控线程、1个错误监控线程
根据自己的虚拟机，采用show engine innoDB status\G 语句进行查询，得出下图，因为innoDB Plugin版本增加了默认的read thread和write thread
内存：
缓冲池(buffer pool) 重做日志缓冲池(redo log buffer) 额外的缓冲池(additional memory pool)
由配置文件中innodb_buffer_pool_size和innodb_log_buffer_size的大小决定
buffer pool size 表明了由多少个缓冲帧(buffer frame)，每个缓冲帧为16K，上图中则分配了8192*16/1024=128M的内存的缓冲池
free buffer表示当前空闲的缓冲帧
database pages表示已使用的缓冲帧
modified db pages表示脏页的数量
并非当前状态，从上图可知为51s前的状态
