MySQL性能的五大配置参数(内存参数)

内存参数：

存储引擎/共享
日志缓冲区，缓冲区池

innodb_buffer_pool_size
innodb_additional_mem_pool_size
innodb_log_buffer_size

服务器/共享
查询调整缓存
线程高速络缓存

query_cache
table_cahce
table_definition_cache

连接/会话
排序缓冲区，读取缓冲区，临时表

binlog_cache_size
read_buffer_size
read_rnd_buffer_size
join_buffer_size
sort_buffer_size
tmp_table_size
thread_cache_size
bulk_insert_buffer_size
net_buffer_length
thread_stack

下面转载自：http://www.bitscn.com/pdb/mysql/201405/227583.html

*.线程独享内存
*.全局共享内存
全局共享内存类似ORACLE的系统全局区SGA，线程独享内存类似ORACLE的进程全局区PGA

一、线程独享内存

在MySQL中，线程独享内存主要用于各客户端连接线程存储各种操作的独享数据，如线程栈信息，分组排序操作，数据读写缓冲，结果集暂存等等，而且大多数可以通过相关参数来控制内存的使用量。

* 线程栈信息使用内存(thread_stack)：
主要用来存放每一个线程自身的标识信息，如线程id，线程运行时基本信息等等，我们可以通过 thread_stack 参数来设置为每一个线程栈分配多大的内存。
Global,No Dynamic,Default 192K(32bit), 256K(32bit),
推荐配置：默认

* 排序使用内存(sort_buffer_size)：
MySQL 用此内存区域进行排序操作(filesort)，完成客户端的排序请求。当我们设置的排序区缓存大小无法满足排序实际所需内存的时候，MySQL会将数据写入磁盘文件来完成排序。由于磁盘和内存的读写性能完全不在一个数量级，
所以sort_buffer_size参数对排序操作的性能影响*对不可小视。排序操作的实现原理请参考：MySQL Order By的实现分析。
什么时候会用到？
对结果集排序时
使用确认：
可以通过查询计划中的Extra列的值为Using file-sort来证实使用了和这个缓冲区。
>explain select * from user1;
Global Session,Dynamic,Default 2M(32bit), 2M(32bit),
推荐配置：8M（内存足够的情况下），默认（内存紧张的情况）
优化建议：一种说法是增大可以提高order by,group by性能，防止数据写入磁盘占用IO资源，还有一种说法是不推荐增加这个缓冲区的大小，理由是当值太大时可能会降低查询的执行速度。目前我没有实验证实。

* 顺序读取数据缓冲区使用内存(read_buffer_size)：
这部分内存主要用于当需要顺序读取数据的时候，如无法使用索引的情况下的全表扫描，全索引扫描等。在这种时候，MySQL按照数据的存储顺序依次读取数据块，每次读取的数据快首先会暂存在read_buffer_size中，
当buffer空间被写满或者全部数据读取结束后，再将buffer中的数据返回给上层调用者，以提高效率。
Global Session,Dynamic,Default 128K
推荐配置：4M/8M

* 随机读取数据缓冲区使用内存(read_rnd_buffer_size)：
和顺序读取相反，当MySQL进行非顺序读取（随机读取）数据块的时候，会利用这个缓冲区暂存读取的数据。如根据索引信息读取表数据，根据排序后的结果集与表进行Join等等。
总的来说，就是当数据块的读取需要满足一定的顺序的情况下，MySQL就需要产生随机读取，进而使用到read_rnd_buffer_size 参数所设置的内存缓冲区。
Global Session,Dynamic,Default 256K
推荐配置：8M

* 连接信息及返回客户端前结果集暂存使用内存(net_buffer_lenth)：
这部分用来存放客户端连接线程的连接信息和返回客户端的结果集。当MySQL开始产生可以返回的结果集，会在通过网络返回给客户端请求线程之前，会先暂存在通过net_buffer_lenth所设置的缓冲区中，
等满足一定大小的时候才开始向客户端发送，以提高网络传输效率。不过net_buffer_lenth参数所设置的仅仅只是该缓存区的初始化大小，MySQL会根据实际需要自行申请更多的内存以满足需求，
但*大不会超过 max_allowed_packet 参数大小。
Global Session,Dynamic,Default 16K
推荐配置：默认 16K

* 批量插入暂存使用内存(bulk_insert_buffer_size)：
当我们使用如 insert … values(…),(…),(…)… 的方式进行批量插入的时候，MySQL会先将提交的数据放如一个缓存空间中，当该缓存空间被写满或者提交完所有数据之后，MySQL才会一次性将该缓存空间中的数据写入数据库并清空缓存。
此外，当我们进行 LOAD DATA INFILE操作来将文本文件中的数据Load进数据库的时候，同样会使用到此缓冲区。
Global Session,Dynamic,Default 8M
推荐配置：默认 8M
* 临时表使用内存(tmp_table_size)：
当我们进行一些特殊操作如需要使用临时表才能完成的Order By,Group By 等等，MySQL可能需要使用到临时表。当我们的临时表较小（小于tmp_table_size 参数所设置的大小）的时候，MySQL会将临时表创建成内存临时表，
只有当tmp_table_size所设置的大小无法装下整个临时表的时候，MySQL才会将该表创建成MyISAM存储引擎的表存放在磁盘上。不过，当另一个系统参数 max_heap_table_size 的大小还小于 tmp_table_size 的时候，
MySQL将使用 max_heap_table_size 参数所设置大小作为*大的内存临时表大小，而忽略tmp_table_size 所设置的值。而且 tmp_table_size 参数从 MySQL 5.1.2 才开始有，之前一直使用 max_heap_table_size。
谁小谁生效.另外还有一个参数max_tmp_tables,没有使用
tmp_table_size
Global Session,Dynamic,Default 16M
推荐配置：64M
max_heap_table_size
Global Session,Dynamic,Default 8M
This variable sets the maximum size to which user-created MEMORY tables are permitted to grow
这个变量定义了MEMORY存储引擎表的*大容量。
This variable is also used in conjunction with tmp_table_size to limit the size of internal in-memory tables. See
这个变量也与tmp_table_size一起使用限制内部内存表的大小。请见
http://dev.mysql.com/doc/refman/5.5/en/internal-temporary-tables.html
推荐配置：64M
主要根据业务以及服务器内存来调整，如果有需要到则可以调整到。GB居然使用2G的配置，汗

补充说明：上面所列举的MySQL线程独享内存仅仅只是所有线程独享内存中的部分，并不是全部，只是这些可能对MySQL的性能产生较大的影响，且可以通过系统参数进行调节。
由于以上内存都是线程独享，*端情况下的内存总体使用量将是所有连接线程的总倍数。所以在设置过程中一定要谨慎，切不可为了提升性能就盲目的增大各参数值，
避免因为内存不够而产生Out Of Memory异常或者是严重的Swap交换反而降低整体性能。

二、全局共享内存

全局共享内则主要是MySQL Instance以及底层存储引擎用来暂存各种全局运算及可共享的暂存信息，如
存储查询缓存的 Query Cache，
缓存连接线程的 Thread Cache，
缓存表文件句柄信息的 Table Cache，
缓存二进制日志的 BinLog Buffer，
缓存MyISAM存储引擎索引键的 Key Buffer
存储InnoDB数据和索引的 InnoDB Buffer Pool
等等。下面针对 MySQL 主要的共享内存进行一个简单的分析。

* MyISAM索引缓存 Key Buffer（key_buffer_size）：
MyISAM 索引缓存将MyISAM表的索引信息（.MYI文件）缓存在内存中，以提高其访问性能。这个缓存可以说是影响MyISAM存储引擎性能的*重要因素之一了，通过 key_buffere_size 设置可以使用的*大内存空间。
注意：即使运行一个全部采用innodb的模式，仍需要定义一个索引码缓冲区，因为MYSQL元信息与MyISAM定义相同。
Global ,Dynamic,Default 8M
推荐配置：默认 8M
如何确认key_buffer_size不够用？
使用show full proceslist的State列中，值Repairing the keycache是一个明显的指标，它指出当前索引码缓冲区大小不足以执行当前运行的SQL语句。这将导致额外的磁盘I/O开销。

* 查询缓存 Query Cache （query_cache_size）：
http://dev.mysql.com/doc/refman/5.5/en/query-cache-configuration.html
http://dev.mysql.com/doc/refman/5.5/en/query-cache-status-and-maintenance.html
查询缓存是MySQL比较独特的一个缓存区域，用来缓存特定Query的结果集（Result Set）信息，且共享给所有客户端。通过对Query语句进行特定的Hash计算之后与结果集对应存放在Query Cache中，以提高完全相同的Query语句的相应速度。
当我们打开MySQL的Query Cache之后，MySQL接收到每一个SELECT类型的Query之后都会首先通过固定的Hash算法得到该Query的Hash值，然后到Query Cache中查找是否有对应的Query Cache。如果有，则直接将Cache的结果集返回给客户端。
如果没有，再进行后续操作，得到对应的结果集之后将该结果集缓存到Query Cache中，再返回给客户端。当任何一个表的数据发生任何变化之后，与该表相关的所有Query Cache全部会失效，所以Query Cache对变更比较频繁的表并不是非常适用，
但对那些变更较少的表是非常合适的，可以*大程度的提高查询效率，如那些静态资源表，配置表等等。为了尽可能高效的利用Query Cache，MySQL针对Query Cache设计了多个query_cache_type值
和两个Query Hint：SQL_CACHE和SQL_NO_CACHE。当query_cache_type设置为0（或者 OFF）的时候不使用Query Cache，当设置为1（或者 ON）的时候，当且仅当Query中使用了SQL_NO_CACHE 的时候MySQL会忽略Query Cache，
当query_cache_type设置为2（或者DEMAND）的时候，当且仅当Query中使用了SQL_CACHE提示之后，MySQL才会针对该Query使用Query Cache。可以通过query_cache_size来设置可以使用的*大内存空间。
Global Dynamic,Default 0
推荐配置：16M
如何确定系统query cache的情况？
show global status like ‘Qcache%’;或者
select * from information_schema.GLOBAL_STATUS where VARIABLE_NAME like ‘Qcache%’;
公式：
（Qcache_hits/Qcache_hits+Com_select+1)*100来确定查询缓存的有效性
mysql> show variables like ‘query_cache_size’;
+——————+———-+
| Variable_name | Value |
+——————+———-+
| query_cache_size | 16777216 |
+——————+———-+
1 row in set (0.00 sec)
mysql> show global status like ‘Qcache%’;
+————————-+————+
| Variable_name | Value |
+————————-+————+
| Qcache_free_blocks | 535 |
| Qcache_free_memory | 4885448 |
| Qcache_hits | 1858574835 |
| Qcache_inserts | 1619931831 |
| Qcache_lowmem_prunes | 802889469 |
| Qcache_not_cached | 825000679 |
| Qcache_queries_in_cache | 4411 |
| Qcache_total_blocks | 9554 |
+————————-+————+
8 rows in set (0.00 sec)
mysql> show global status like ‘Com_select’;
+—————+————+
| Variable_name | Value |
+—————+————+
| Com_select | 2445037535 |
+—————+————+
1 row in set (0.00 sec)

* 连接线程缓存 Thread Cache（thread_cache_size）：
连接线程是MySQL为了提高创建连接线程的效率，将部分空闲的连接线程保持在一个缓存区以备新进连接请求的时候使用，这尤其对那些使用短连接的应用程序来说可以*大的提高创建连接的效率。
当我们通过thread_cache_size设置了连接线程缓存池可以缓存的连接线程的大小之后，可以通过(Connections – Threads_created) / Connections * 100% 计算出连接线程缓存的命中率。
注意，这里设置的是可以缓存的连接线程的数目，而不是内存空间的大小。
Global,Dynamic,Default 0
推荐配置：8个
如何确定系统Thread Cache的情况？
mysql> show global status like ‘Threads_created’;
+—————–+——-+
| Variable_name | Value |
+—————–+——-+
| Threads_created | 506 |
+—————–+——-+
1 row in set (0.00 sec)

* 表缓存 Table Cache（table_open_cache）：
表缓存区主要用来缓存表文件的文件句柄信息，在 MySQL5.1.3之前的版本通过table_cache参数设置，但从MySQL5.1.3开始改为table_open_cache来设置其大小。当我们的客户端程序提交Query给MySQL的时候，
MySQL需要对Query所涉及到的每一个表都取得一个表文件句柄信息，如果没有Table Cache，那么MySQL就不得不频繁的进行打开关闭文件操作，无疑会对系统性能产生一定的影响，Table Cache 正是为了解决这一问题而产生的。
在有了Table Cache之后，MySQL每次需要获取某个表文件的句柄信息的时候，首先会到Table Cache中查找是否存在空闲状态的表文件句柄。如果有，则取出直接使用，没有的话就只能进行打开文件操作获得文件句柄信息。
在使用完之后，MySQL会将该文件句柄信息再放回Table Cache 池中，以供其他线程使用。注意，这里设置的是可以缓存的表文件句柄信息的数目，而不是内存空间的大小。
Global,Dynamic,Default 400
推荐配置：根据内存配置4G 2048 大于*大Opened_tables
如何确定系统table_open_cache的情况？
mysql> show variables like ‘table_open_cache’;
+——————+——-+
| Variable_name | Value |
+——————+——-+
| table_open_cache | 512 |
+——————+——-+
1 row in set (0.00 sec)
mysql> show global status like ‘open%_tables’;
+—————+——-+
| Variable_name | Value |
+—————+——-+
| Open_tables | 512 |
| Opened_tables | 6841 |
+—————+——-+
2 rows in set (0.00 sec)
调优参考：
http://blog.zfcms.com/article/282
http://www.kuqin.com/database/20120815/328904.html
两个参数的值。其中Open_tables是当前正在打开表的数量，Opened_tables是所有已经打开表的数量。
如果Open_tables的值已经接近table_cache的值，且Opened_tables还在不断变大，则说明mysql正在将缓存的表释放以容纳新的表，此时可能需要加大table_cache的值。对于大多数情况，比较适合的值：
Open_tables / Opened_tables >= 0.85
Open_tables / table_cache <= 0.95
如果对此参数的把握不是很准，VPS管理百科给出一个很保守的设置建议：把MySQL数据库放在生产环境中试运行一段时间，然后把参数的值调整得比Opened_tables的数值大一些，并且保证在比较高负载的*端条件下依然比Opened_tables略大。
在mysql默认安装情况下，table_cache的值在2G内存以下的机器中的值默认时256到 512，如果机器有4G内存,则默认这个值是2048，

* 表定义信息缓存 Table definition Cache （table_definition_cache）：
表定义信息缓存是从 MySQL5.1.3 版本才开始引入的一个新的缓存区，用来存放表定义信息。当我们的 MySQL 中使用了较多的表的时候，此缓存无疑会提高对表定义信息的访问效率。
MySQL 提供了 table_definition_cache 参数给我们设置可以缓存的表的数量。注意，这里设置的是可以缓存的表定义信息的数目，而不是内存空间的大小。
The number of table definitions (from .frm files) that can be stored in the definition cache. If you use a large number of tables, you can create a large table definition cache to speed up opening of tables.
Global, Dynamic, Default 400
推荐配置：根据内存配置4G 2048 和Table Cache一样即可

* 二进制日志缓冲区Binlog Cache( binlog_cache_size）：
二进制日志缓冲区主要用来缓存由于各种数据变更操做所产生的 Binary Log 信息。为了提高系统的性能，MySQL 并不是每次都是将二进制日志直接写入 Log File，而是先将信息写入 Binlog Buffer 中，
当满足某些特定的条件（如 sync_binlog参数设置）之后再一次写入 Log File 中。我们可以通过 binlog_cache_size 来设置其可以使用的内存大小，同时通过 max_binlog_cache_size 限制其*大大小
（当单个事务过大的时候 MySQL 会申请更多的内存）。当所需内存大于 max_binlog_cache_size 参数设置的时候，MySQL 会报错：“Multi-statement transaction required more than ‘max_binlog_cache_size’ bytes of storage”。
Global,Dynamic,Default 32K
推荐配置：2M

* InnoDB 日志缓冲区 InnoDB Log Buffer （innodb_log_buffer_size）：
这是 InnoDB 存储引擎的事务日志所使用的缓冲区。类似于 Binlog Buffer，InnoDB 在写事务日志的时候，为了提高性能，也是先将信息写入 Innofb Log Buffer 中，当满足 innodb_flush_log_trx_commit 参数所设置的相应条件（或者日志缓冲区写满）之后，才会将日志写到文件（或者同步到磁盘）中。可以通过 innodb_log_buffer_size 参数设置其可以使用的*大内存空间。
注：innodb_flush_log_trx_commit 参数对 InnoDB Log 的写入性能有非常关键的影响。该参数可以设置为0，1，2，解释如下：

0：log buffer中的数据将以每秒一次的频率写入到log file中，且同时会进行文件系统到磁盘的同步操作，但是每个事务的commit并不会触发任何log buffer 到log file的刷新或者文件系统到磁盘的刷新操作；
1：在每次事务提交的时候将log buffer 中的数据都会写入到log file，同时也会触发文件系统到磁盘的同步；
2：事务提交会触发log buffer 到log file的刷新，但并不会触发磁盘文件系统到磁盘的同步。此外，每秒会有一次文件系统到磁盘同步操作。
此外，MySQL文档中还提到，这几种设置中的每秒同步一次的机制，可能并不会完全确保非常准确的每秒就一定会发生同步，还取决于进程调度的问题。实际上，InnoDB 能否真正满足此参数所设置值代表的意义正常 Recovery 还是受到了不同 OS 下文件系统以及磁盘本身的限制，可能有些时候在并没有真正完成磁盘同步的情况下也会告诉 mysqld 已经完成了磁盘同步。

Global,Dynamic,Default 8M
推荐配置：8M 默认

* InnoDB 数据和索引缓存 InnoDB Buffer Pool（innodb_buffer_pool_size）：
InnoDB Buffer Pool 对 InnoDB 存储引擎的作用类似于 Key Buffer Cache 对 MyISAM 存储引擎的影响，主要的不同在于 InnoDB Buffer Pool 不仅仅缓存索引数据，还会缓存表的数据，
而且完全按照数据文件中的数据快结构信息来缓存，这一点和 Oracle SGA 中的 database buffer cache 非常类似。所以，InnoDB Buffer Pool 对 InnoDB 存储引擎的性能影响之大就可想而知了。
可以通过 (Innodb_buffer_pool_read_requests – Innodb_buffer_pool_reads) / Innodb_buffer_pool_read_requests * 100% 计算得到 InnoDB Buffer Pool 的命中率。
global级别，不可动态变更 Default 128M
设置InnoDB数据和索引内存缓存空间大小
配置方式：配置文件中配置
选择参数：50 – 80 % RAM

mysql> show variables like ‘%innodb_buffer%’;
+——————————+———–+
| Variable_name | Value |
+——————————+———–+
| innodb_buffer_pool_instances | 1 |
| innodb_buffer_pool_size | 268435456 |
+——————————+———–+
2 rows in set (0.00 sec)
通过show global status和show engine innodb status/G的BUFFER POOL AND MEMORY
mysql> show global status like ‘%innodb_buffer%’;
+—————————————+————–+
| Variable_name | Value |
+—————————————+————–+
| Innodb_buffer_pool_pages_data | 15684 |
| Innodb_buffer_pool_bytes_data | 256966656 |
| Innodb_buffer_pool_pages_dirty | 210 |
| Innodb_buffer_pool_bytes_dirty | 3440640 |
| Innodb_buffer_pool_pages_flushed | 372378403 |
| Innodb_buffer_pool_pages_free | 1 |
| Innodb_buffer_pool_pages_misc | 698 |
| Innodb_buffer_pool_pages_total | 16383 |
| Innodb_buffer_pool_read_ahead_rnd | 0 |
| Innodb_buffer_pool_read_ahead | 691803 |
| Innodb_buffer_pool_read_ahead_evicted | 41350 |
| Innodb_buffer_pool_read_requests | 170965099291 |
| Innodb_buffer_pool_reads | 5392513 |
| Innodb_buffer_pool_wait_free | 0 |
| Innodb_buffer_pool_write_requests | 5825388207 |
+—————————————+————–+
15 rows in set (0.01 sec)

mysql> show engine innodb status/G
BUFFER POOL AND MEMORY
———————-
Total memory allocated 274726912; in additional pool allocated 0
Dictionary memory allocated 4055091
Buffer pool size 16383
Free buffers 1
Database pages 15673
Old database pages 5765
Modified db pages 521
Pending reads 0
Pending writes: LRU 0, flush list 0, single page 0
Pages made young 27497746, not young 0
0.00 youngs/s, 0.00 non-youngs/s
Pages read 6346456, created 1902566, written 372381712
0.00 reads/s, 0.37 creates/s, 27.75 writes/s
Buffer pool hit rate 1000 / 1000, young-making rate 0 / 1000 not 0 / 1000
Pages read ahead 0.00/s, evicted without access 0.00/s, Random read ahead 0.00/s
LRU len: 15673, unzip_LRU len: 0
I/O sum[1107]:cur[0], unzip sum[0]:cur[0]
命中率 Innodb_buffer_pool_read_requests – Innodb_buffer_pool_reads) / Innodb_buffer_pool_read_requests * 100%
170965099291-5392513/170965099291 × 100% = 99.99%

* InnoDB 字典信息缓存 InnoDB Additional Memory Pool（innodb_additional_mem_pool_size）:
InnoDB 字典信息缓存主要用来存放 InnoDB 存储引擎的字典信息以及一些 internal 的共享数据结构信息。所以其大小也与系统中所使用的 InnoDB 存储引擎表的数量有较大关系。不过，如果我们通过 innodb_additional_mem_pool_size 参数所设置的内存大小不够，InnoDB 会自动申请更多的内存，并在 MySQL 的 Error Log 中记录警告信息。
global级别，不可动态变更 Default 8M
设置InnoDB存放数据库字典信息的Buffer大小
推荐配置：50M

三、查看统计

1.查看各参数内存配置方式
#全局共享内存 9个变量
show variables like ‘innodb_buffer_pool_size’; /* InnoDB 数据和索引缓存（InnoDB Buffer Pool） */
show variables like ‘innodb_additional_mem_pool_size’; /* InnoDB 字典信息缓存（InnoDB Additional Memory Pool）*/
show variables like ‘innodb_log_buffer_size’; /* InnoDB 日志缓冲区（InnoDB Log Buffer） */
show variables like ‘binlog_cache_size’; /* 二进制日志缓冲区（Binlog Buffer）*/
show variables like ‘thread_cache_size’; /* 连接线程缓存（Thread Cache）*/
show variables like ‘query_cache_size’; /* 查询缓存（Query Cache）*/
show variables like ‘table_open_cache’; /* 表缓存（Table Cache） */
show variables like ‘table_definition_cache’; /* 表定义信息缓存（Table definition Cache） */
show variables like ‘key_buffer_size’; /* MyISAM索引缓存（Key Buffer） */
#*大线程数
show variables like ‘max_connections’;
#线程独享内存 6个变量
show variables like ‘thread_stack’; /* 线线程栈信息使用内存(thread_stack) */
show variables like ‘sort_buffer_size’; /* 排序使用内存(sort_buffer_size) */
show variables like ‘join_buffer_size’; /* Join操作使用内存(join_buffer_size) */
show variables like ‘read_buffer_size’; /* 顺序读取数据缓冲区使用内存(read_buffer_size) */
show variables like ‘read_rnd_buffer_size’; /* 随机读取数据缓冲区使用内存(read_rnd_buffer_size) */
show variables like ‘tmp_table_size’; /* 临时表使用内存(tmp_table_size) ，我实际计算把tmp_table_size放入全局共享内*/
也可以通过系统变量的方式直接获取
select @@key_buffer_size;
select @@max_connections

2.mysql内存计算公式
mysql使用的内存 = 全局共享内存+*大线程数×线程独享内存
mysql used mem=innodb_buffer_pool_size+innodb_additional_mem_pool_size+innodb_log_buffer_size+binlog_cache_size+thread_cache_size+query_cache_size+table_open_cache+table_definition_cache+key_buffer_size
+max_connections*（
thread_stack+sort_buffer_size+join_buffer_size+read_buffer_size+read_rnd_buffer_size+tmp_table_size）

SET @kilo_bytes=1024;
SET @mega_bytes=@kilo_bytes*1024;
SET @giga_bytes=@mega_bytes*1024;
SELECT (@@innodb_buffer_pool_size+@@innodb_additional_mem_pool_size+@@innodb_log_buffer_size+@@binlog_cache_size+@@thread_cache_size+@@query_cache_size+@@table_open_cache+@@table_definition_cache+@@key_buffer_size+@@max_connections*(@@thread_stack+@@sort_buffer_size+@@join_buffer_size+@@read_buffer_size+@@read_rnd_buffer_size+@@tmp_table_size))/@giga_bytes AS MAX_MEMORY_GB;

这个理论*大的内存使用量，在5.5版本中tmp_table_size默认是16M，按默认u自大连接数151计算，光线程独享的临时表占据的空间都是2416M，我实际计算把tmp_table_size放入全局共享内
我的计算公式
mysql使用的内存 = 全局共享内存+*大线程数×线程独享内存
mysql used mem=innodb_buffer_pool_size+innodb_additional_mem_pool_size+innodb_log_buffer_size+binlog_cache_size+thread_cache_size+query_cache_size+table_open_cache+table_definition_cache+key_buffer_size+tmp_table_size
+max_connections*（
thread_stack+sort_buffer_size+join_buffer_size+read_buffer_size+read_rnd_buffer_size）

mysql 小配置_如何配置全世界小的 MySQL 服务器

配置全世界*小的 MySQL 服务器——如何在一块 Intel Edison 为控制板上安装一个 MySQL 服务器。

介绍

在我*近的一篇博文中，物联网，消息以及 MySQL，我展示了如果Particle Photon 的板子开始构建你自己的物联网。那个实现很棒，不过因为 Particle Photon 板子没有任何本地的存储，所以需要稳定的互联网(wi-fi)接入。如果你没有一个可靠的网络访问 (例如在一些边远的地方) 或者需要某些很小的东西来存储数据，现在就可以使用Intel Edison了。我甚至在Edison 安装过 MySQL，这使其成为了世界上(在体积上)*小的 MySQL 服务器！其它的选择包括：

Raspberry Pi(我的大学同学在 Raspberry PI 上面安装了 Percona 服务端)

基于 Android 的系统 (例如 Nexus 7: Vadim 在 Nexus 7 上安装了 Percona 服务端)

MySQL 配置

Intel Edison是一个小巧的计算机，基于 22 nm 的 Silvermont 双核 Intel Atom CPU，主频 500MHz，运行 Linux (叫做 Yocto 的基于 Ubuntu 的发布版)。为了对 Edison 进行编程，我们需要一块接口板。可以选择的板子包括兼容 Arduino 的接口板 (包含了 SD 卡) 还有 Intel 接口板。

安装和配置是直观的。我使用了在 Intel Edison 板子上开启 Yocto 项目的指南来对板子进行安装和配置。首先我们需要通过串口来连接 Edison，并对 sshd 和 Wi-Fi 进行配置；完成后我们就可以使用 SSH 连接到 Edison 了。

因为 Linux 通用的二进制文件是兼容 Yocto Linux 的(因而你无需编译任何东西)，所以 MySQL 的安装相对比较简单. 有两个坑：

Yocto linux (还有官方的资源库) 默认并没有包含 MySQL 所需要的库: libaio1, libcrypto, libssl

内部存储比较小，而 MySQL 5.7 二进制文件不适合放到任何分区。我必须删除一些 “tests”以及其它我并不需要的东西。真正安装的时候可以使用 SD 卡 (SD 插叙在一些板子上是有的)。

为了安装库文件，我遵照这份优秀的指南：Edison 包 repo 配置，使用了非官方的 Edison 资源库。设置很简单：

要配置你的 Edison 从这个 repo 获取包，请用下面这些东西替换掉 /etc/opkg/base-feeds.conf 中的东西(其它 opkg 配置文件不需要改变)：

src/gzallhttp://repo.opkg.net/edison/repo/allsrc/gzedisonhttp://repo.opkg.net/edison/repo/edisonsrc/gzcore2-32http://repo.opkg.net/edison/repo/core2-32[/code]

之后我们需要对库进行安装：

#opkginstalllibaio1_0.3libcrypto1.0.0libssl1.0.0[/code]

*后我们可以下载 Percona Server 5.6 并将其放到某个地方 (使用 my.cnf 中的 basedir 指向安装路径)：

#wgethttps://www.percona.com/downloads/Percona-Server-5.6/Percona-Server-5.6.25-73.1/binary/tarball/Percona-Server-5.6.25-rel73.1-Linux.i686.ssl100.tar.gz[/code]

请注意*新的 Percona Server 5.6 依赖于 Numa 库，而对于 Yocto 没有这样的库 (对 Edison不影响)。因此 5.6.25 是你可以在这里安装的*新的 Percona 服务端。

下面在 Intel Edison 上所进行的简单(并且相当无用 )的基准测试：

root@edison:/usr/local/mysql#cat/proc/cpuinfoprocessor:0vendor_id:GenuineIntelcpufamily:6model:74modelname:GenuineIntel(R)CPU4000@500MHz…mysql>SELECTBENCHMARK(10000000,ENCODE(‘hello’,’goodbye’));+———————————————–+|BENCHMARK(10000000,ENCODE(‘hello’,’goodbye’))|+———————————————–+|0|+———————————————–+1rowinset(18.77sec)[/code]

MySQL 可以为你烤面包吗?

著名的 MySQL Bug#2, 提交于 2002 年 9 月12 号，并说明“MySQL Connector/J 并不能烤面包”。使用 Intel Edison 和 Arduino 兼容的接口板现在就可以修复这个 bug 了: 现在不仅 MySQL Connector/J ， MySQL 服务端本身也可以为你烤面包了 ! 这可以借助于 UDF，或者在 MySQL 5.7中使用Query Rewrite 插件，因此你可以执行MySQL 查询：

mysql>maketoast;[/code]

对于实际的实现，你既可以”黑“掉一个手头的烤面包机来接入接口板的针脚，或者使用兼容 Arduino 的Robotic Arm。好了， MySQL，为我烤面包吧!

mysql 软硬件平台要求_MySQL的*低硬件要求？

这个问题源自”菲利普“大叔”(菲利普大叔乃我们MySQL的大区销售，此人英俊潇洒、风流倜傥、玉树临风、神勇威武、幽默风趣、趣fei闻不断……?实在是编不下去了，饭要?出来了)昨日中午，正当我享受幸福的午饭时光，一通电话打扰了我的悠闲。“客户问了我一个问题，徐老师解答一下”。给菲利普解答了之后，我又担心“大叔”年纪大了，记忆力不好，说过的经常忘，我还是写下来，以备将来他再找我时不认账。

其实，在我的日常工作中经常能够遇到这个问题，这个问题通常来自客户的系统管理员或者是采购人员，原因基本有两个：

完全对数据库产品没有概念，不清楚对硬件的要求。

对MySQL数据库不熟悉，参照以往的商业数据库进行比较。

写下这篇文字回答一下这个问题，以供对MySQL数据库不熟悉的人员参考。

MySQL究竟有没有*低的硬件要求呢？翻遍整个手册的内容你也找不到相关信息，除了MySQL NDB Cluster，但是NDB又和大家通常意识里的MySQL完全不同，因此你可以理解为MySQL对服务器的硬件没有*低要求。有人马上就会问：“怎么可能？在PC上面安装个软件还有*低要求呢” 别着急，往下看。MySQL在官网上提供了一个支持运行的操作系统一览表：“https://www.mysql.com/support/supportedplatforms/database.html”，上面记述了Oracle验证过的可以正常运行MySQL的操作系统。

这个一览表相当于从侧面提供了一个硬件*低要求，只要你的服务器能够正常安装使用所支持的操作系统，MySQL即可在服务器上运行。换句话说，MySQL对硬件的要求非常低，不需要高大上的硬件支持，这也是MySQL流行起来的根本原因之一。

数据库产品与其他应用产品不同，随着数据库变得越来越繁忙，任何数据库应用程序*终都会达到硬件*限。因此，在*初为数据库配置硬件时，需要考虑应用的类型，数据量的增长，为未来一段时间做好规划，做好性能和成本的平衡。

mysql 服务器要求_mysql 服务器配置

Windows:

1.在bin目录下执行mysqld.exe –install-manual安装服务(删除命令是mysqld.exe –remove)

2.执行net start mysql启动服务(停止服务net stop mysql)

3.修改root密码,执行mysqladmin -uroot -p password后先输入默认密码然后输入新密码(默认密码为空)

Linux:

1.解压MySQL-5.6.25-1.linux_glibc2.5.i386.rpm-bundle.tar(tar -xvf MySQL-5.6.25-1.linux_glibc2.5.i386.rpm-bundle.tar)

2.检查系统中是否已安装mysql(rpm -qa|grep -i mysql)

3.安装mysql服务端(rpm -ivh MySQL-server-5.6.25-1.linux_glibc2.5.i386.rpm)，若提示error: Failed dependencies: libaio.so.1 is needed ，则执行 yum install libaio

4.启动mysql服务(service mysql start)

5.检测mysql是否启动成功(/etc/rc.d/init.d/mysql status)

6.登陆，默认会为root生成一个随机密码，在/root/.mysql_secret里

7.允许root远程连接(否则连接报错host is not allowed to connect mysql):mysql>GRANT ALL PRIVILEGES ON *.* TO ‘root’@’%’ IDENTIFIED BY ‘root’ WITH GRANT OPTION;(可能会要求先修改密码，执行SET PASSWORD = PASSWORD(‘123456’); )

8.修改默认密码:mysql>update user set password=PASSWORD(‘123456′) where user=’root’;　　mysql>FLUSH PRIVILEGES;

做mysql服务器需要什么配置好_佳的MySQL服务器配置以获得性能？

我们有一个使用MyIsam表运行MySQL 5.0.45的大小为150 GB的数据库,有一些大表的大小超过5 GB,索引为2GB.

服务器配置为：

8GB

双核3.2GHz –启用超线程

一次突袭5-SCSI

1GB网卡

64位操作系统

这是我们的my.cnf文件：

[client]

port = 3306

socket = /var/lib/mysql/mysql.sock

[mysqld]

log=/var/log/mysqld.log

log-slow-queries=/var/log/mysqld-slow.log

set-variable=long_query_time=2

set-variable=sql_mode=ANSI_QUOTES

port = 3306

socket = /var/lib/mysql/mysql.sock

skip-locking

max_connections = 100

key_buffer = 384M

max_allowed_packet = 16M

table_cache = 512

sort_buffer_size = 2M

read_buffer_size = 2M

read_rnd_buffer_size = 8M

myisam_sort_buffer_size = 64M

thread_cache = 8

query_cache_size = 32M

thread_concurrency = 3

[isamchk]

key_buffer = 256M

sort_buffer_size = 256M

read_buffer = 2M

write_buffer = 2M

[myisamchk]

key_buffer = 256M

sort_buffer_size = 256M

read_buffer = 2M

write_buffer = 2M

[mysqldump]

quick

max_allowed_packet = 16M

[mysql]

no-auto-rehash

[isamchk]

key_buffer = 256M

sort_buffer_size = 256M

read_buffer = 2M

write_buffer = 2M

[myisamchk]

key_buffer = 256M

sort_buffer_size = 256M

read_buffer = 2M

write_buffer = 2M

非常感谢您提出改善查询性能的建议(读80％/写20％)

Android adb 客户端是如何检测到自定义服务端端口的？

adb 客户端能自动发现局域网中的 adb 服务端，当我手机开启 wireless adb 后，总能收到局域网内其他客户端发出的连接请求，开始以为是通过探测默认端口 5555 实现的，但我把服务端端口改成其他后，仍然能收到连接请求，不知道这是如何实现的，难道是服务端主动向局域网内广播自己的配置？

9 条回复 • 2021-08-02 09:02:03 +08:00

learningman 12 天前

我知道有个叫 SSDP 的协议，估计是差不多的东西吧

yukiww233 12 天前

问下局域网内其他人(adb client)是怎么发送请求连接的呗
没准人家写了个工具遍历局域网内端口

wjploop 12 天前

有趣的问题

我也认为不是服务端自己广播自己的配置，手机不该浪费自己电量来做这事，而是客户端主动探测出来的。

客户端如何探测？

使用 nmap 工具查询当前局域网活跃的主机以及开放的端口 /服务，我下载玩了会，当手机开放无线 adbd 时确实可以检测到，且手机开放的端口很少，根据手机开放端口很少这点，客户端只要尝试连接就行了。

不知道现实中你指的客户端是谁，可能是公司的测试人员？由于 IP 动态分配的原因连上了你手机？

jim9606 11 天前 5

Android 的 adbd 激活无线调试后会通过 mDNS 发布一个_adb-tls-connect._tcp 服务。
adb v30 开始设置环境变量 ADB_MDNS_OPENSCREEN=1 后，adb devices 会利用 mDNS 自动发现设备。

andyskaura 11 天前

@jim9606 感谢涨姿势了通过 mdns 发现设备

MLawliet 11 天前

@wjploop 目前发现是局域网中跑着 Android studio 、Unity 这类工具的设备会主动向开启无线的 adbd 发起连接请求，这些设备上肯定没有人为跑检测程序

@jim9606 非常感谢，*次知道 mDNS…

xingstar 11 天前

真是学习了，感谢(⊙o⊙)…

aabbcc112233 9 天前

@MLawliet AS 怎么能够向已开启无限调试的设备发起连接呢？没看到入口

MLawliet 8 天前

@aabbcc112233 自动的啊，AS 会自动执行 adb devices 命令查找局域网内开启调试的设备然后连接

Android Rom 开发学习路线求推荐

一直想定制一款自己 Rom 包增加一些特色功能奈何技术有限

求大佬指一条学习路线… (目前本人会点点 Java 和基础的 C)

我是打算基于：魔趣或者 Lineageos 开发的.

5 条回复 • 2021-08-09 09:19:26 +08:00

rrZ2C 7 天前

我觉得参考 https://wiki.pixelexperience.org/devices/violet/build/ 就不错

pixelexperience 通常分两个版本
常规分支:主动集成 gms 的版本
puls 分支:有额外特色功能,比如通知栏增强热点增强等等

可以对照看一下对方的实现方式

windyboy 7 天前

了解安卓是前提吧
先学学人家的贡献指引，看看怎么本地 build 一下

ikas 7 天前

如果只是基于 Lineageos 这些,没什么复杂的..按照他们的 wiki,搞好环境下好源码,试着编译一次..然后用 ide 导入你需要修改的项目..然后修改就是了…后面就是无聊的修改,编译,copy 到手机覆盖文件,重启测试…

sahooz 6 天前 via Android

同准备魔改 Android 系统，哎，就是玩。目前感觉了解 Java，大概了解 Android 系统的架构，了解源码的编译方法，然后就可以各种魔改了。当然 HAL 这种太底层的我是不会的，改改 framework 就差不多了

FATEQiang 1 天前

Android 10 + pix3L 定制过。1 、电脑配置要好，不然编译 rom 包很慢，就算单编也难受； 2 、要看定制深度，直接下载 lineageOS 的源代码感觉没有 Android 源码直接搞好，因为源码直接编译的 ROM 有很多问题，这样边改边学很好； 3 、官网的 Android10 R40 可以用 px3L + ，可以支持 Android 和车载系统，车载*近挺火的； 4 、LineargeOS 需要的设备大多是国内的，不知道刷机的时候坑可能多

谷歌版微信 8.x 版本不能使用小程序

打开所有小程序都是提示小程序组件更新中。
以前用 7.0，可以下载一个 obb 文件，现在 8.x 找不到合适的 obb 文件好像也不能操作那个目录了。
我是哇为手机，不能安装 Google play （也许能但是太麻烦了），是用 ourora 安装了 gp 版微信。
在没有 Google play 的情况下，有办法解决这个问题吗？
试过 debugmm.qq.com/?forcex5=false 不行。有什么办法解决吗

67 条回复 • 2021-08-09 12:58:17 +08:00

xiaomengy 7 天前 via Android

开代理打开微信会自动下载 obb

xiaomengy 7 天前 via Android

没有 Google play …………有点悬

jsyzdej 7 天前 via Android

换手机

hzqim 7 天前

在此基础上再安装一个 MicroG 试试？

philipjf 7 天前

建议下载安装和谐 os 版微信

HzMz 7 天前 via Android

我的能用小程序啊，8.0.2，S20+，Android 11

JensenQian 7 天前

鸿蒙现在可以安装 gms 了，我在 youtube 上看到有教程的

liyiecho 7 天前

你需要安装完整版的微信，完整版 370 多 M，可以试试这个 https://h5.cloud.189.cn/share.html#/t/aE3iaeZ3QZbm

Citrus 7 天前

没有 GP 装 GP 版那只能自己想办法搞个 obb 了。。。这玩意本来是连 GP 自动下载的啊

juded 7 天前

play 版微信国内用太 bug 了，小程序日常打不开，消息延迟转圈，万年不更新，*后忍无可忍换回国内版了。
play 的好处是广告少，打开文档不会诱导下载 qq 浏览器。

fishrimp 7 天前 via Android

@HzMz 你有 Google play 吧

fishrimp 7 天前 via Android

@juded 主要是感觉流畅一些

fishrimp 7 天前 via Android

@liyiecho 这种完整版怎么来的？以后出新版了去哪里找完整版

scxiazi 7 天前

play 更新慢但是也更新到 8.0.2 了

h82258652 7 天前

rom 问题。上个星期傻逼 MIUI 自己更新 12.5 了，把我 google play 搞炸了。然后我刷了国际版 MIUI，google play 微信里的小程序是能用的。后来因为玩的手游会检测 BL 锁，锁上国际版的 rom 就进不去，刷回国内版 MIUI 了，然后 google play 的微信的小程序也是显示小程序组件更新中的，所以多半应该就是 rom 的问题。

dickinpit 7 天前

@liyiecho #8 为什么我的是 500 多……机型不同，不一样？

dickinpit 7 天前

@juded #10 只用过谷歌版，没比较，但感觉广告也不少……订阅流、公众号文章底部、朋友圈都是包圆儿的

maosj 7 天前 via Android 1

play 市场 8.0 以上版本微信，好像用了新的 abb 打包方式。开代理，微信里点小程序，然后打开 play 市场微信 app 页面，会显示下载拓展包，下载完成后，小程序能正常使用。

titanium98118 7 天前

昨天刚更新到 8.0.2，正常打开小程序

liyiecho 7 天前

@fishrimp #13 酷安微信评论区别人分享的?
@dickinpit #16 370 多 M 是下载包的大小，你 500 多看的是安装后应用的大小吧？

riggzh 7 天前

8.0+以上使用的是 aab，可以使用 SAI 一类的安装工具安装 apks

Cielsky 7 天前

你找个完整包安上就行了

dickinpit 7 天前

@liyiecho #20 是的

est 7 天前

小程序按道理来说本来就不合规吧。等于绕过 appstore 自己搞一套代替分发机制。

jim9606 7 天前 2

Google Play 已经停止支持 obb 了，现在用的是 App Bundles，微信已经换了。
建议去 APKMirror 下载 8.0.2(注意不是 8.0.9，有 variant 的版本才有可能是 GP 的)
建议用这个纯 arm64 480dpi 的版本，这个版本没有压缩原生库，安装时能省些空间。
( https://www.apkmirror.com/apk/wechat-tencent/wechat/wechat-8-0-2-release/wechat-8-0-2-6-android-apk-download/ )

jim9606 7 天前

@est TX 能跟 Apple 谈妥你还担心 GP 那边出问题，前者比后者严格多了，GP 那边只要内购那边没问题，Google 基本不会找开发者麻烦。

jim9606 7 天前

@dickinpit 目前 Google Play 推送的版本有 5 个 split apk，也就是我发的 apkmirror 那个，其中 split_delivery**模块是打开 APP 后补充的，缺了这个可能打不开小程序。可以用 LibChecker 检查。

![]( https://i.loli.net/2021/08/03/dTG2nNCZR1egjyH.jpg)
![]( https://i.loli.net/2021/08/03/ovXtLfzgsBpc5yE.jpg)

580M 是 5 个 split apk 和 odex 优化代码的空间，由于没有压缩原生库，不需要额外解压原生库占更多空间。

zhea55 7 天前

@riggzh 跟 aab 没关系吧。谷歌只是要求开发者上传 aab，实际安装的还是 apk 。

我用谷歌 play 版本微信，功能正常。谷歌版本微信好像没有内置腾讯的 x6 内核。

用的原装系统 webview

WuwuGin 7 天前

这个问题我刚更新也遇见了，然后等了一晚上就好了。。。所以推测确实在更新啥东西。

cuixiao603 7 天前

@HzMz #6 多开微信可以打开小程序了吗

tenwx 7 天前 3

一加 9pro 遇到个问题就是*次点击微信小程序会一直在加载转圈圈，必须退出去，重新点击小程序，第二次才能打开，用的是 gp 的 8.0.2 版

dickinpit 7 天前

@jim9606 #27 多谢！

ZeroSimple 7 天前 via Android 1

@tenwx 我也是，一模一样的症状，Pixel Android 12，微信 Play 版 8.0.2

he0119 7 天前 2

@ZeroSimple 我也是，不过可以根据 https://www.v2ex.com/t/789389#r_10702045 关掉关闭 X5 内核，应该就没事了。

rabi 7 天前 1

新版 play 微信不是下载 obb 文件，但会提示正在下载 extensions,然后就可以使用小程序了，但每次进小程序都会转圈，不用管，返回再进入就可以了。这问题不知道腾讯会不会改进。

yongso 7 天前 via Android

@tenwx 一加 7p 也是的

yongso 7 天前 via Android

@rabi 只能烧烧香了

rabi 7 天前

但我没记错的话，之前从 7 版本升上来的时候是没有这个问题的。

lizenghui 7 天前

TB 上几十块钱给华为装 google play 试过没。

tankren 6 天前

我已经换回应用宝版本了没什么区别啥毛病都没有

SelFree 6 天前 1

用了两个周，换回 7.0.x 了。
公众号打开除了*近一条新消息，下面全是推荐其它公众号的。
比以前偶尔夹一条推荐过分到不知哪里去了。

https://i.loli.net/2021/08/03/bzmfH2jDuncPOlt.png

hellokangning 6 天前

@tenwx 小米 10 也是

Maskeney 6 天前 via Android

@he0119 没用，forcex5=false 之后依然要二次打开小程序

fishrimp 6 天前 via Android

@jim9606 这个是包含小程序的完整版吗？才 200 多 m

SupperCoder 6 天前

@SelFree 问下，GooglePaly 商品的微信版本怎么回退？

SelFree 6 天前

@SupperCoder 我是在 apkpure 下的旧版

fishrimp 6 天前 via Android

@riggzh 包含小程序的 apks 哪里找呢

fishrimp 6 天前 via Android

@SelFree 一直不升级也不是办法啊，以后会封了旧版的，而且新版有想要的功能

fishrimp 6 天前 via Android

@Cielsky 完整包哪里找呢

Cielsky 6 天前 via Android

@fishrimp https://my-file.cn/s/gKLtd?path=%2F
1851，300 多 m 吧。

让别人提取出来 apks，然后用 sai 安装应该也可以吧

jim9606 6 天前

@fishrimp 这个是支持小程序的。apkm 就是一个 zip 包，你可以解压看看里面有什么东西。
关于 Webview 我不是很清楚 GP 版微信小程序是否依赖系统 Webview，个人认为不依赖。

jim9606 6 天前

@Cielsky 300M 的这个是同时包含 armv7 和 arm64 的 fat binary 版本，不是老旧的 armv7 手机没必要用这个。图省事不在乎多占 400M 安装空间的也可以用。

Cielsky 6 天前

@jim9606 他没 play 商店，有的话直接上去更新就可以了

sephinh 6 天前 via iPhone

要不完整包，要不就 play 里更新个补充包，选那个看自己手机环境吧

evgm 6 天前

下载 xapk 安装包，解压出 obb 文件，复制到手机 /sdacrd/android/obb/com.tencent.mm 文件夹下

VENIVIDIVICI 6 天前

https://www.apkmirror.com/apk/wechat-tencent/wechat/

riggzh 6 天前

@zhea55 #28 主程序 apk 缺少打开小程序的依赖，这部分依赖是在 aab 里的，aab 的东西不能直接装，可以找人导出后用 SAI 安装

fishrimp 6 天前 via Android

@jim9606 下载了你说的纯 arm64 480dpi 版本，小程序可以用了。请教以后版本更新了，如何在 apkmirror 找这种完整版呢？

kaedea 6 天前 via Android

不要使用任何第三方渠道的包，apkpure 上面的 apks 包也是有问题的，gp 包就必须从 play store 安装，自己想办法解决跟 Play Service 的鉴权问题，成功下载资源包即可。

ysc3839 6 天前 via Android

@zhea55 Android 是有支持 Split APK 的，开发者提交 AAB，对于不支持 Split APK 的系统，服务器会根据设备生成单个 apk，对于支持 Split APK 的系统，服务器下发各个部分的 apk 。

Ley 6 天前 via Android

那么多年都是从 Play 商店下载安装的微信，好像完全没有遇到过这类问题。主楼的问题是因为从第三方安装的吗？

LittleControl 6 天前

我也是 play *新版 wechat, 小程序*下都是显示一直加载中,打不开,但是每次返回再重新打开一下就可以了
有点玄学

jim9606 6 天前

@kaedea
升级安装会检查 apk 签名是否一致，能装上就行，顶多就是同一开发者不同分发渠道，通常设计上都不会有问题。楼主遇到的是 App Bundles 相关的问题。

@fishrimp
虽然 apkmirror 说会人工审核，但并因为都是用户上传，没法可靠地标注来源，所以建议下载之前现在 play 市场查一下上架的*新版本，例如现在查到是 8.0.2 那就只下 8.0.2 。

这里我之所以选的不是 versioncode *大的 1860 而是采用 bundles 格式的 1852 是因为我手工检查过几个支持 arm64 的版本的内部情况，只有我发的那个版本符合“单一 ABI”+“未压缩原生库”这两个要求。我也不明白为啥单一 ABI 的包还要压缩来浪费安装空间，连 Google 自家产品都没统一这点。

ChenXuting 5 天前

Mate 20，“Harmony OS 2.0.0”安装 Play 正常。

reiji 5 天前

安卓 12，GP 版的小程序扫码后老是卡在加载的转圈圈，装了普通版本的才能正常用

kaedea 5 天前 via Android

@ChenXuting 真是

nnxs 1 天前 via Android

@tenwx 一加 8T,一模一样的情况,还好小程序用的不多…

Android 开发工具兼容性/版本搭配

由于几个月前电脑 CPU 烧了，被迫换了 M1 的 Mac Mini，所以整个开发环境重新搭建了一遍。趁这个机会，我想整理几个基础工具的版本搭配策略、兼容性、以及在 M1 芯片上的表现。对于版本搭配和兼容性的一些讨论不局限于当前使用的版本和平台。

下方提及的版本分别是：

Zulu JDK: 11.0.11
Kotlin: 1.5.21
Gradle: 7.1.1
Android Gradle Plugin （ AGP ）: 7.0 & 7.1
Android Studio: Arctic Fox 2020.3.1 & BumbleBee 2021.1.1 Canary 6

JDK

自 AGP 7.0 起，JDK 11 便是*低要求。JDK 11 成为 LTS （ Long-term Support) 版本已经有将近 3 年历史（ Sep 2018 ），自身经历了 12 个小版本（ 11.0.12 ）的迭代目前相对成熟了。作为对比，上一个 LTS 的 JDK 8 2014 年发布，已经陪着我们走过了 7 年时光和 300 个小版本迭代。事实上作为 Android 开发者，即便目前项目是 Java 为主的情况，一般 Language Level 也仅 target to 1.8 （一些 9-12 的特性 D8 、R8 有支持，Android 11 12 也有融入）。Android 官方虽然说不会放弃 Java，但实际上对 Kotlin 的支持确实更给力。

从这个角度来看，JDK 11 带来给我们的更多是：

Kotlin Compiler 、Gradle 、IDE 层面上性能的升级；
JDK 8 将停止维护的情况下（ 3 年后），安全层面的持续保障；
适应新的发布机制，每半年一个小版本，三年一个 LTS 大版本，减少历史包袱跑得更快；

而 JDK 的升级策略我认为是：

保守派：如果不在意新语言特性，可以等每年 AGP 升级的情况来决定 JDK 的版本，因为 IDE 一般 bundle 了一个 JDK，Kotlin 编译器、Gradle 一直追着*新 JDK 并有不错的向下兼容——所以根据木桶原理等 AGP 升级了再升即可，目前看来 AGP 可能也只跟进比较稳定的 LTS 版本；
激进派：Gradle 支持后即可测试；

在 M1 Mac 上，由于 Oracle 还未有的 ARM64 版本，所以目前主流的做法是安装 Azul 维护的 Zulu JDK11。

%title插图%num

需要注意的是，常用的 JDK 管理工具 SDKMAN! 在我的测试中依旧跑在 Rosetta 2 的转译环境中。这会造成即便你是安装的 Zulu JDK11，通过 SDKMAN! 的脚本启动依然会显示 Gradle java 的进程跑在 Intel ABI 下。故目前建议从官网下载安装，等后续配套工具支持后再考虑切换。

%title插图%num

Kotlin

Kotlin 的版本搭配限制相对不多，一般我考虑三个点：

有没有特别吸引人的新功能，比如刚放出稳定版的 Coroutine 、Flow，或者新版本 Kotlin Multiplatform Mobile 的更好支持等；
用不用大迭代的*个版本，例如观察刚发布时的 1.4.0，1.5.0，这条其实广泛适用于各类 Library ；
Gradle 目前 bundle/test 的 Kotlin 的版本，例如*新的 7.1.1 stable 依旧是用的 1.4.31 的 Kotlin （ 7.2 RC 则跳到 1.5.21 了）；

关于*后一点，如果使用的 Kotlin 版本和 Gradle bundle 的不一致，会出现如下 Warning：

w: Runtime JAR files in the classpath should have the same version. >These files were found in the classpath: … /Users/2bab/.gradle/caches/modules-2/files-2.1/org.jetbrains.kotlin/kotlin-stdlib-jdk7/1.4.31/84ce8e85f6e84270b2b501d44e9f0ba6ff64fa71/kotlin-stdlib-jdk7-1.4.31.jar (version 1.4) /Users/2bab/.gradle/caches/modules-2/files-2.1/org.jetbrains.kotlin/kotlin-stdlib/1.5.21/2f537cad7e9eeb9da73738c8812e1e4cf9b62e4e/kotlin-stdlib-1.5.21.jar (version 1.5) /Users/2bab/.gradle/caches/modules-2/files-2.1/org.jetbrains.kotlin/kotlin-stdlib-common/1.5.21/cc8bf3586fd2ebcf234058b9440bb406e62dfacb/kotlin-stdlib-common-1.5.21.jar (version 1.5) w: Consider providing an explicit dependency on kotlin-reflect 1.5 to prevent strange errors w: Some runtime JAR files in the classpath have an incompatible version. Consider removing them from the

用一个简单的例子看下问题是怎么发生的：

plugins {
    id("com.android.application")
    // 没有指定版本，用的就是 Gradle bundle 的版本，
    // Gradle 7.1.1 对应的就是 Kotlin 1.4.31 的各种类库和编译工具
    kotlin("android") 
}

dependencies {
    // 而这里我们却用了 1.5.21 的*新版 Kotlin，就会出现如上问题
    implementation("org.jetbrains.kotlin:kotlin-stdlib:1.5.21")
}

解决起来也很简单：

plugins {
    id("com.android.application")
    // 手动指定版本
    kotlin("android") version "1.5.21"
}

Kotlin 官方的文档直接就演示了加版本号的写法。但是，这个版本是 Kotlin 基于 Gradle 测试通过，而 Gradle 自身还没有基于它测试过并打包进去（见 Gradle 部分的配图），若出现了问题可能难以解决：

所以我推荐的升级策略是：

保守派：等 Gradle 升级的时候再升级，例如 1.5.0 到 1.5.21 中间仅隔了两个月，Gradle 就跟进了；
激进派：有实用的新功能或者大版本迭代后的*个补丁版本就升。

Gradle

前面提到 Kotlin 的官方文档解释了各类和 Gradle 配合兼容的情况，反过来 Gradle 这边也有一个标明了 Java 、Kotlin 、Android 等各语言和平台的支持文档。

%title插图%num

像前面提到的 Java 版本支持，Kotlin 版本支持在这里便一目了然。除了 Kotlin 的支持会稍落后一两个月，其他工具的*新版本兼容都不成问题。而 Gradle 自身的向下兼容我觉得还不错，我基本上每个版本都升级。而上层的 AGP DSL，特别是老版本，则挺经常有大改动（好在 7.0 后终于强多了）。

所以我推荐的升级策略是：

保守派：根据 AGP 的文档按*低版本进行升级（详见下图），例如 AGP 4.2.0+ 对应 Gradle 6.7.1+；
激进派：每个补丁版本(x.y.1/2/3)或者每个版本都升（ Gradle 没有 -betaX 的版本习惯，一般就是 Nightly 和 RC ）。

%title插图%num

另外，Gradle 7.0 后的版本原生支持了 M1，我个人的使用体验还不错。

Android Gradle Plugin

AGP 的版本搭配限制我们在前面基本都介绍完了，以 7.0 为例，我们来看官方 Release Note 的兼容说明：

%title插图%num

额外补充一点：从 AGP 7.0 起，其版本会同步 Gradle 的 major 版本，严格遵守 Semantic Versioning 体系（之前同步的是 AS 的版本）。也即 AGP 7.x 会适配 Gradle 7.x 的版本。不过 AGP 的发布时间依旧是随着 AS 一起发布，并且目前来看其 alpha/beta 的数字是跟随 AS 的，所以其实可以当成三者形成了某种默契的同步机制。

所以我推荐的升级策略是：

保守派：随 AS 正式版升级（或适当跳过*个大版本更迭）；
激进派：每个版本都升，或从 alpha/beta 开始升级，例如要做 Gradle 插件适配。

Android Studio

AS 基本上没有什么搭配限制，只要你用的之前正式版的 AGP，AS 就可以向下兼容。我推荐的升级策略是：

保守派：适当跳过*个大版本更迭；
激进派：每个版本都升，或从 alpha/beta 开始升级，例如要做 IDE 插件适配或者对 Compose 、调试工具新功能等有需求的。

另外，由于 AS 基于的 IDEA 社区版二次开发，整体稳定性、新特性支持的速度都不如 IDEA Ultimate，例如 Gradle 的 nesting Composite Build 目前就不在 AS 支持范围，见该 issue。

*后，自 Arctic Fox 2020.3.1 起，AS 原生支持了 M1，但如果想有更流畅的体验，我认为 BumbleBee 2021.1.1 Canary 效果更好一些。

IDEA

IDEA 的主要搭配限制来自于 Android Plugin （ Android IDE 插件）的版本适配。一般来说，在 AS 新的正式版本发布之后，下一个 IDEA 的正式版本就会带上该新版插件，从而对 Android 开发包括 AGP 做支持。

%title插图%num

偶尔也有等比较久的时候，比如今年 AS&AGP 4.2 在 4 月发布，而直到 7 月 IDEA 2021.2 发布时，才更新了 Android Plugin，官方的说法是 Google 放出 AGP 4.2 的源码时间晚了些，导致没赶上 2021.1 的版本。

我推荐的升级策略是：

保守派：仅升级正式版本；
激进派：从 EAP 或 RC 开始升级，例如会获得比较好的 Kotlin 支持、更早的 AGP 支持，以及 M1 平台的优化等。

*后，2021.2 也是让我在 M1 感觉终于不再有什么卡顿的版本了。

总结

我自己由于使用 M1 的平台 + 适配一些 Gradle Plugin，经常会使用 beta 甚至 alpha 的 AGP （作为 Runtime 的 library ），配合*新的 IDEA Ultimate 开发起来还是挺顺手。

而公司项目，现阶段 x86 平台我觉得可以使用如下配置，ARM M1 则根据上文调整对应的工具版本：

JDK 11 （由于 AGP 升了迟早要升级）
Gradle 7.1.1 （ 7.2 支持 1.5.21 后可以升级）
Kotlin 1.4.31
AGP 4.2.2 （ 7.0 稳定了新版的 Variant API，马上 7.1 也稳定新版的 DSL，不需要 Compose 的话可以观望观望）
AS 4.2.2 （不需要 Compose 的话可以观望观望）
IDEA 2021.2

异形屏的时代终于要过去了吗？

MIX4 使用了屏下镜头技术，正面是一块完整的屏幕。等到明年应该会有更多的手机使用这一技术吧

78 条回复 • 2021-08-10 13:27:42 +08:00

emeab 22 小时 48 分钟前 28

全面屏不过是伪需求罢了

luhe 22 小时 47 分钟前 via iPhone

1080P 不感兴趣，上下做个等宽就那么难

wat4me 22 小时 46 分钟前 11

中兴屏下镜头手机都发售了两代了

philipjf 22 小时 30 分钟前

@luhe 大法不就是上下等宽

JQSM 22 小时 28 分钟前 via Android

中兴今年发的这款已经看不出来了，相比去年进步很大，估计明年友商们都能铺开量产了。

x86 22 小时 28 分钟前 1

中兴都二胎了，小米有资格叫？

Patrick95 22 小时 27 分钟前

@emeab #1 展开说说？

wangxn 22 小时 17 分钟前 via iPhone

等这一天很久了，这才是真正的全面屏。

hahastudio 22 小时 13 分钟前

我只期待什么时候手机屏幕可以给我渲染出来 (0, 0)

ljsh093 21 小时 58 分钟前 8

别说了，有人不喜欢

clrss 21 小时 56 分钟前 2

手持 iPhone SE2 笑看花里胡哨.

misdake 21 小时 52 分钟前

*早的伸缩前摄不就已经是一整块了嘛

namelosw 21 小时 47 分钟前

之前忘了哪款，虽然是屏下镜头但是那块区域的分辨率会减半，然后摄像头很糊。希望这个能做好点…

Leviathann 21 小时 6 分钟前

@namelosw 可以了解下中兴的 axon2，第二代的屏下摄像头区域显示效果改善了不少

Leviathann 21 小时 2 分钟前

@namelosw 打错，是 axon 30

WenhaoWu 21 小时 2 分钟前 via Android

屏幕比例还是问题，希望大法快点跟进 21：9 的真全面屏

Morii 20 小时 59 分钟前 24

@clrss #11 se2 就别笑看了真的

tankren 20 小时 44 分钟前

屏下摄像头多迭代几代应该就能跟现在的屏下指纹一样可以大规模上市了

monkey110 20 小时 34 分钟前

苹果异形屏扛把子

lscexpress 20 小时 31 分钟前 2

苹果什么样，安卓大概率就什么样

LiYanHong 20 小时 27 分钟前

还早，什么时候苹果用了才会结束，苹果近几代肯定不会用的

X0ray 20 小时 25 分钟前 12

还在吹苹果。。。现在安卓已经走在前面了

Building 20 小时 23 分钟前 via iPhone

你们说的那种全面屏…和 iPhone 的显示效果有可比性吗？ Face ID 放哪里？

topc101 20 小时 21 分钟前

再这样发展下去。屏下发声、屏下电源键、Esim 卡。。。。
那手机不就光板一块

imnpc 20 小时 18 分钟前

苹果没有采用的话是因为苹果前置各种传感器比较多不好解决

0o0o0o0 20 小时 9 分钟前 15

晕孔晕水滴晕刘海全面屏对我来说是真需求

shyrock 20 小时 3 分钟前

全面屏在我看来跟曲面屏之类的差不多，主要收益是外观更漂亮。
增加的那点屏幕面积对使用（点击、游戏、看视频）的影响微乎其微。
也许对特别看重手机装饰属性的人很重要吧，对我这种拿手机当工具的人完全无感（当初买 S7E 就是看着曲面屏酷炫，一个月后就审美疲劳了）

dallaslu 19 小时 57 分钟前

@Morii 哭着看行吗？

Pichai 19 小时 54 分钟前

屏下镜头的技术还不完整，中兴*新发布的那个，自拍的时候感觉就是加了一层白色的薄膜，看着非常不自然。应该是屏幕反射原因导致的吧。具体可以参考那个快男钟汶泽的视频。

suzic 19 小时 45 分钟前 via Android

全面屏对我来说是真需求

Pichai 19 小时 41 分钟前

@Pichai 看了下 ppt 。小米说他们解决了这个雾化的问题。不清楚是真解决了还是在 ppt 上解决的。

wangkun025 19 小时 39 分钟前

全面屏和屏占比，对我来说都没意义。

jin7 19 小时 38 分钟前

红米一亿像素的手机扫屏幕上的二维码还不太顺畅

zhangbohun 19 小时 33 分钟前 1

红米 K30Pro 用户表示，就算是全面屏，四个圆角还是很挫，什么时候才能再有正常矩形的屏幕。。

ZField 19 小时 32 分钟前

可惜了不想买小米了……

threebr 19 小时 19 分钟前

@Pichai 算法上解决的，肯定比不上挖空的效果。另外白蒙蒙的感觉可能是衍射产生的

chiu 17 小时 36 分钟前

中兴：你们身边真的没有人用中兴手机吗？ [doge]

AEDaydreamer 14 小时 5 分钟前 1

有人觉得无所谓，还有的人比如我就是刚需啊。实在接受不了异形屏。

hanxiV2EX 14 小时 0 分钟前 via Android

就看真机表现如何了

hanxiV2EX 13 小时 54 分钟前 via Android

https://m.youtube.com/watch?v=3AVIqdeDQ5o

这个中兴第二代很强了

powerman 6 小时 51 分钟前

国产还在搞这些花里胡哨的东西，苹果家的玩意光是生态系统跟多设备联合使用的感觉，吊打一大片安卓了

chanchan 5 小时 1 分钟前

?爹不改异形屏就是对的

1if5ty3 4 小时 34 分钟前

说个大家不爱听的，苹果发布了 xx，xx 的时代才能到来。

0o0o0o0 4 小时 4 分钟前

苹果手机没发布高刷新率，可是现在高刷新了已经成为标配了。
其次苹果生态的确很不错，安卓生态拉跨，可是安卓很多功能性方面要比苹果强，而且苹果估计一时半会儿都不会加入这些功能。
只能说各有优势。

yellowV2ex 4 小时 3 分钟前

现在各家用户都已经被系统捆绑了，中兴再牛逼也没用，硬件可以拼，但 OS 不是你想追就能追上的

cheng6563 4 小时 1 分钟前

中兴的系统现在还是剁手兴吗？

noahhhh 3 小时 57 分钟前 via Android

@jin7 处理器带不动

iamthegrad 3 小时 56 分钟前 9

说全面屏是伪需求的真是放屁

chenyu8674 3 小时 37 分钟前 3

扫码不爱戴套党表示不突出的摄像头才是刚需

lingxipaofan 3 小时 35 分钟前

手持 SE2 的那个笑死我了

jfdnet 3 小时 34 分钟前

目前屏下摄像头只能装配 1080p 大果粒屏。继续观望。

calease 3 小时 27 分钟前

都是成年人了，怎么还整天跟个孩子一样，小米 PPT 说什么你就信什么。

SimleCp 2 小时 47 分钟前

@powerman 生态, 软件, 硬件, 哎.

plk403 2 小时 43 分钟前

四边等宽很难吗摩托那款新的好像差不多了 pixel 那个也是都是得用柔性屏

XMD 2 小时 42 分钟前 1

生异形啊你们哥俩（幻视

philipjf 2 小时 39 分钟前

@Building 安卓没有用 Face ID 的

philipjf 2 小时 36 分钟前

@plk403 四边等宽成本高啊，pixel5 用上了的结果就是 765 买的比 888 都贵，国内一堆用着廉价大下巴“超窄边”屏的，利润比用全面屏的 iPhone 和 pixel 不知道高到哪里去了

Scare 2 小时 29 分钟前

得看 Apple 了吧。。。Apple 如果用全面屏，估计其他厂商也都跟进，然后就没有异形屏了吧。
记得当时 Apple 出 iPhone X 的时候，都说不好看，可是全都比着他的样子发布的新机

Felldeadbird 2 小时 20 分钟前

中兴二代评测看过了，特定角度还是可以看出屏幕不一样的像素点。明年确实会铺开屏下摄像头了。

echo314 2 小时 16 分钟前

下一步，追求直角全面屏！！！

直角！！！

不要圆角！！！

christin 2 小时 14 分钟前 via iPhone

去年市场上的刘海屏水滴屏挖孔屏升降式摄像头更像是为了数据好看而往前赶。

CuSO4 2 小时 0 分钟前

目前还不行，这一代前置屏下自拍雾蒙蒙的

powerman 1 小时 59 分钟前

现在搞这种硬件飙升级真的没什么卵用了，要提升下用户体验，很多用户基本上被系统绑定住了，你想让苹果迁移到安卓太难了，我 mbp macmini airtag iphone applewatch ipad 基本上苹果家有的，我都买了，你让我切换到安卓，太难了

clrss 1 小时 51 分钟前

@Morii 我就是要笑看.

当然不是说 SE 比花里胡哨先进.
而是花里胡哨对我来说没什么卵用.

Morii 1 小时 36 分钟前

@clrss #64

个人理解：笑看代表有「优越感」

MaverickLee 1 小时 33 分钟前

@emeab #1 伪不伪需求另说。但异形屏(刘海、挖孔、美人尖)确实是憨批

hantsuki 1 小时 3 分钟前

@zhangbohun 而且圆角弧度还特别大，真挫，有文字要显示在边角看着就很难受，比如看电子书的时候。像 mix2 那种弧度就刚刚好

ftu 41 分钟前 1

如果苹果出真全面屏：改变世界！

国产牌子出真全面屏：伪需求！

PostMeridiem18 40 分钟前

索尼或成*大赢家（

Pogbag 38 分钟前

生异形啊你们哥几..哥俩

Axnir 23 分钟前 via iPhone

对重量更敏感，屏幕形状不感兴趣

sprite82 21 分钟前

只要果子没有的，都是伪需求，果子用了的，是成熟的，是未来方向
这句话以前是真理，未来很长一段时间还是真理

l00t 20 分钟前

@powerman 生态多设备之类的, 苹果有什么资格跟小米说话.

mikeven 16 分钟前

全面屏除了一点观感差别之外，，好像也没什么用，看视频如果不是 21：9 的话也没差别

felixcode 12 分钟前 via Android

果粉承包了各帖的笑点。

0o0o0o0 12 分钟前

@christin #61 升降式摄像头除了会重一点其他都很完美。

@jfdnet #51 的确，本身屏下那一块提升到 1080p 就很难了。

@plk403 #54 现在好像高端的都是柔性屏了，四边等宽等于其他三边要加宽，厂商这么做就少了一个卖点，不过四边等宽和三边窄各有优势。

@philipjf #57 国产高端的底边好像早就比苹果窄了。

@powerman #63 互相切换本身就挺难的。

se2 屏幕太小了，真的伤眼

gablic 9 分钟前

苹果首发刘海屏：nb ！
安卓首发真·全面屏：花里胡哨！

djFFFFF 7 分钟前

大胆点，智能手机对我来说就不是刚需?

2021 年 8 月
一	二	三	四	五	六	日
						1
2	3	4	5	6	7	8
9	10	11	12	13	14	15
16	17	18	19	20	21	22
23	24	25	26	27	28	29
30	31