在小米 10 至尊紀(jì)念版的評(píng)測(cè)視頻已進(jìn)入后期剪輯階段后，我發(fā)現(xiàn)它的屏幕有些意思——它采用的 OLED 面板并不是來(lái)自于三星，而是國(guó)內(nèi)供應(yīng)商華星光電。
這件事情可以通過(guò)兩點(diǎn)來(lái)驗(yàn)證：
一是該屏幕顯示任何字樣時(shí)，其次像素渲染方式都與三星不同——這塊屏的橫縱筆畫(huà)都支持次像素渲染，而三星 OLED 屏幕僅縱向筆畫(huà)支持次像素渲染；
二是，我所調(diào)取的小米 10 至尊紀(jì)念版系統(tǒng) BugReport 文件中，也的確顯示其 OLED 面板來(lái)自華星光電。
小米旗艦機(jī)用的不是三星 OLED 屏，而是一塊我此前沒(méi)見(jiàn)過(guò)的高端國(guó)產(chǎn)屏，新鮮了，得「求真」一波。我于是就緊急跑回 FView Lab 做了關(guān)于這塊屏幕的更多測(cè)試，現(xiàn)在為大家呈現(xiàn)下結(jié)果。
在 FView Lab 的電子顯微鏡下，我們可以看到，該顯示面板采用與三星面板相同的 Pentile 鉆石排列。因此，其等效 RGB PPI 計(jì)算方式也與三星面板完全相同。
而顯微鏡下我們也能以微觀形式觀察其顯示字樣時(shí)的次像素渲染方式：橫向與縱向筆畫(huà)邊緣處都能從筆畫(huà)外的像素中「借」子像素，因此字的邊緣都為「紅 + 藍(lán)」的規(guī)則樣式，反映到宏觀上就是字體邊緣規(guī)整、不出彩邊。
小米 10 至尊紀(jì)念版 次像素排列 & 次像素渲染
但是三星屏顯示文字時(shí)的銳度會(huì)比小米 10 至尊紀(jì)念版這塊華星光電屏更高一點(diǎn)，這就導(dǎo)致后者雖然支持更完善的次像素渲染，但顯示文字的字號(hào)較小時(shí)，略不如同尺寸的三星屏幕（比如小米 10 Pro）那樣銳利。
——但是，如果你不像我一樣，因?yàn)樨潏D大尺寸屏幕上更多的顯示內(nèi)容，而把 DPI 調(diào)得特別高；或者不像 404 同志那樣對(duì)于字體筆畫(huà)邊緣的彩邊過(guò)分敏感，那可能你也看不出兩者的太大區(qū)別。
該屏幕面板默認(rèn)采用 PWM 調(diào)光，在調(diào)至 120Hz 刷新率、手動(dòng)亮度 50％ 時(shí)，測(cè)得其頻閃頻率約 480Hz、波動(dòng)深度 91.8%、閃爍百分比 84.88%、閃爍指數(shù) 0.402。將刷新率降至 60Hz 后，頻閃頻率也降至 240Hz。
小米 10 至尊紀(jì)念版 頻閃
小米 10 Pro 頻閃
MIUI 12 在顯示設(shè)置中提供了防頻閃功能，但需要將刷新率強(qiáng)行降至 60Hz 才可開(kāi)啟。值得一提的是，小米 10 Pro 在啟用防頻閃模式時(shí)，可以維持 90Hz 的屏幕刷新率。
小米 10 至尊紀(jì)念版這塊屏幕的光譜，其藍(lán)光波峰約 460nm，與我們手里的小米 10 Pro 一致，基本規(guī)避了對(duì)人眼傷害最大的短波藍(lán)光，但會(huì)有效抑制褪黑素分泌，所以夜里躺床上還是少玩為好。
小米 10 至尊紀(jì)念版 光譜
小米 10 Pro 光譜
除此之外，小米 10 至尊紀(jì)念版的屏幕在日常屏顯亮度、HDR 視頻亮度、色準(zhǔn)等多個(gè)維度的客觀素質(zhì)表現(xiàn)上都很優(yōu)秀，大家可以在愛(ài)否科技的小米 10 至尊紀(jì)念版評(píng)測(cè)視頻中看到這些數(shù)據(jù)。
以上是關(guān)于小米 10 至尊紀(jì)念版在這塊華星光電屏幕面板上的補(bǔ)充內(nèi)容。
撰文/子章
作者：雷文霆
愛(ài)可生華東交付服務(wù)部 DBA 成員，主要負(fù)責(zé)Mysql故障處理及相關(guān)技術(shù)支持。愛(ài)好看書(shū)，電影。座右銘，每一個(gè)不曾起舞的日子，都是對(duì)生命的辜負(fù)。
本文來(lái)源：原創(chuàng)投稿
*愛(ài)可生開(kāi)源社區(qū)出品，原創(chuàng)內(nèi)容未經(jīng)授權(quán)不得隨意使用，轉(zhuǎn)載請(qǐng)聯(lián)系小編并注明來(lái)源。
在 MySQL5.7.30 主從讀寫(xiě)分離環(huán)境下，從庫(kù)在某天出現(xiàn)了 MySQL crash.
系統(tǒng)側(cè): 監(jiān)控顯示該從庫(kù)主機(jī)的內(nèi)存和CPU資源使用率在故障前后均正常，磁盤(pán)IO有2%的iowait（讀寫(xiě)200M/s），說(shuō)明故障前磁盤(pán)存在壓力。
服務(wù)側(cè)：slow-log 中記錄了服務(wù)重啟前，存在使用了臨時(shí)表和文件排序的慢 SQL 語(yǔ)句。
Error-log 中記錄了服務(wù)調(diào)用到 btr0btr.cc 文件 的 L2165 行，出現(xiàn)了 err==DB_SUCCESS 報(bào)錯(cuò)。
0x7f2dd49d0700 InnoDB: Assertion failure in thread 139834817316608 in file btr0btr.cc line 2165
InnoDB: Failing assertion: err==DB_SUCCESS
InnoDB: We intentionally generate a memory trap.
InnoDB: Submit a detailed bug report to http://bugs.mysql.com.
在系統(tǒng)側(cè)排除了磁盤(pán)空間不足和內(nèi)存不足的因素，服務(wù)側(cè)懷疑是慢查詢(xún)和BUG的原因，之后通過(guò)" btr0btr.cc"關(guān)鍵字查找到了一個(gè)類(lèi)似的 BUG 。鏈接如下:
https://bugs.mysql.com/bug.php?id=101154
報(bào)告的意思是，MySQL 在執(zhí)行 btr_insert_on_non_leaf_level_func()函數(shù)時(shí)，寫(xiě)入臨時(shí)表會(huì)導(dǎo)致帶有斷言的服務(wù)崩潰。
通過(guò)查看 btr0btr.cc 文件開(kāi)頭的注釋了解到的原因是：
此文件的調(diào)用機(jī)制是：對(duì)b樹(shù)行操作或記錄所做的所有更改。
L2165 行操作內(nèi)容是：在處理插入到非葉級(jí)別的內(nèi)容時(shí)，會(huì)檢查每個(gè)級(jí)別的可用空間(需保留2倍索引數(shù)高度的頁(yè)空間)，如果在操作之前，葉分裂已經(jīng)開(kāi)始，就很難撤銷(xiāo)，只能通過(guò)崩潰進(jìn)行前滾。**該 BUG 只會(huì)在 MySQL5.7 出現(xiàn) **
代碼查詢(xún)：https://github.com/mysql/mysql-server (通過(guò) Tags 標(biāo)簽選擇對(duì)應(yīng)版本)
代碼內(nèi)容：https://github.com/mysql/mysql-server/blob/mysql-5.7.30/storage/innobase/btr/btr0btr.cc#L2165
nserts a data tuple to a tree on a non-leaf level. It is assumed
that mtr holds an x-latch on the tree. */
void
btr_insert_on_non_leaf_level_func()
---
ut_a(err==DB_SUCCESS);
---
其中ut_a()
https://dev.mysql.com/doc/dev/mysql-server/latest/ut0dbg_8h.html#ae7aed983dfe98ac872b5a9915fa778fa:
檢查數(shù)據(jù)庫(kù)關(guān)于臨時(shí)表的參數(shù)：
innodb_temp_data_file_path ibtmp1:12M:autoextend:max:20G
tmp_table_size 64M 和 max_heap_table_size 64M
注釋?zhuān)簩?shí)際限制取二者中的較小者。會(huì)話級(jí)別的參數(shù)，對(duì)于 innodb_buffer_pool_size 不大且沒(méi)有用到臨時(shí)大數(shù)據(jù)量查詢(xún)的情況，不建議設(shè)置的過(guò)大，可能會(huì)導(dǎo)致內(nèi)存溢出的情況。連接數(shù)800+，64M為推薦值
internal_tmp_disk_storage_engine InnoDB
注釋?zhuān)河糜诙x磁盤(pán)臨時(shí)表的存儲(chǔ)引擎。超出 InnoDB 行或列限制的磁盤(pán)內(nèi)部臨時(shí)表的查詢(xún)會(huì)返回 Row size too large 或 Too many columns 錯(cuò)誤。解決方法是設(shè)置 internal_tmp_disk_storage_engine 為 MYISAM ，我們的 error-log 中無(wú)相關(guān)報(bào)錯(cuò)。初步排查階段不建議修改
created_tmp_disk_tables 2987733
created_tmp_tables 11049848
注釋?zhuān)寒?dāng)在內(nèi)存或磁盤(pán)上創(chuàng)建內(nèi)部臨時(shí)表時(shí)，服務(wù)器會(huì)增加該 Created_tmp_tables值。在磁盤(pán)上創(chuàng)建內(nèi)部臨時(shí)表時(shí)，服務(wù)器會(huì)增加該 Created_tmp_disk_tables值。如果在磁盤(pán)上創(chuàng)建了太多內(nèi)部臨時(shí)表，請(qǐng)考慮增加tmp_table_size和max_heap_table_size設(shè)置。從早上10點(diǎn)36分到17點(diǎn)產(chǎn)生較多臨時(shí)表，結(jié)合業(yè)務(wù)繁忙情況，屬于正常現(xiàn)象
小結(jié): 通過(guò)上面的分析，結(jié)合應(yīng)用架構(gòu)(無(wú)法升級(jí)到 MySQL8.0 )。初步階段是建議先優(yōu)化 SQL 語(yǔ)句，減少對(duì)臨時(shí)表的使用，降低再次發(fā)生的概率。
上文提到的 BUG 報(bào)告中，有個(gè)使用 MySQL Test Run 簡(jiǎn)稱(chēng)MTR(MySQL官方的自動(dòng)化測(cè)試框架) 的測(cè)試用例。
下文將引用此測(cè)試用例，進(jìn)行復(fù)現(xiàn)測(cè)試。
參數(shù)解釋?zhuān)?/span>
innodb_limit_optimistic_insert_debug參數(shù)可以限制每個(gè)B樹(shù)頁(yè)面的記錄數(shù)，在 MySQL 運(yùn)行過(guò)程中動(dòng)態(tài)設(shè)置此參數(shù)可以導(dǎo)致頁(yè)分裂。
innodb_limit_optimistic_insert_debug
限制每個(gè) B 樹(shù)頁(yè)面的記錄數(shù)。默認(rèn)值 0 表示不施加限制。僅當(dāng)使用 CMake選項(xiàng)編譯調(diào)試支持時(shí)，需開(kāi)啟DEBUG選項(xiàng)。
# 依賴(lài)
yum install -y gcc gcc-c++ cmake ncurses ncurses-devel bison openssl openssl-devel
tar -xvf mysql-boost-5.7.30.tar.gz
--編譯安裝MySQL，因?yàn)樾枰O(shè)置innodb_limit_optimistic_insert_debug參數(shù)-------
tar -xvf mysql-boost-5.7.30.tar.gz
# 非BOOST版本的Mysql源碼包，需要指定-DDOWNLOAD_BOOST=1 -DWITH_BOOST=/usr/local/boost
cd mysql-5.7.30
cmake . -DCMAKE_INSTALL_PREFIX=/tools/mysql-test5.7.30 -DMYSQL_DATADIR=/tools/mysql-test5.7.30/data -DMYSQL_UNIX_ADDR=/tools/mysql-test5.7.30/mysql5.7.30.sock -DDEFAULT_CHARSET=utf8mb4 -DDEFAULT_COLLATION=utf8mb4_general_ci -DEXTRA_CHARSETS=all -DENABLED_LOCAL_INFILE=1 -DWITH_SSL=system -DWITH_BOOST=boost -DWITH_DEBUG=1
make
make install
# Cmake 編譯之后會(huì)在DCMAKE_INSTALL_PREFIX目錄中生成mysql-test測(cè)試框架目錄
/tools/mysql-test5.7.30/mysql-test/t
vim my0420.test
cat my0420.test
--source include/have_innodb.inc
--let $restart_parameters="restart: --innodb_temp_data_file_path=ibtmp1:12M:autoextend:max:1G --big-tables=1"
--source include/restart_mysqld.inc
SELECT @@innodb_temp_data_file_path;
drop function if exists func1;
delimiter |;
create function func1(x int) returns int deterministic
begin
declare z1, z2 int;
set z1=x;
set z2=z1 + 2;
return z2;
end|
delimiter ;|
create table t1 (a int, b varchar(20));
insert into t1 values(1, 'a'), (2, 'b'), (3, 'c'), (3, 'c'), (4, 'c');
SET GLOBAL innodb_limit_optimistic_insert_debug=4;
--let $i=1
while ($i <=15) {
INSERT INTO t1 SELECT * FROM t1;
--inc $i
}
SELECT COUNT(*) FROM t1;
SET GLOBAL innodb_limit_optimistic_insert_debug=2;
select * from t1 order by func1(a);
進(jìn)行測(cè)試,
/tools/mysql-test5.7.30/mysql-test
./mtr my0420.test
其中 select * from t1 order by func1(a); 會(huì)使用Using temporary; Using filesort 和 業(yè)務(wù)SQL的執(zhí)行計(jì)劃一致
將 my0420.test 第二行新增--internal_tmp_disk_storage_engine=MYISAM參數(shù)后，服務(wù)不崩潰。
--let $restart_parameters="restart: --innodb_temp_data_file_path=ibtmp1:12M:autoextend:max:1G --internal_tmp_disk_storage_engine=MYISAM --big-tables=1"
將 my0420.test 第二行增大為---innodb_temp_data_file_path=ibtmp1:12M:autoextend:max:6G參數(shù)后，服務(wù)不崩潰。
--let $restart_parameters="restart: --innodb_temp_data_file_path=ibtmp1:12M:autoextend:max:6G --big-tables=1"
big_tables如果啟用，服務(wù)器將所有臨時(shí)表存儲(chǔ)在磁盤(pán)上而不是內(nèi)存中。這可以防止需要大型臨時(shí)表的操作的大多數(shù)錯(cuò)誤，但也會(huì)減慢內(nèi)存表就足夠的查詢(xún)。most The table *tbl_name* is full errors forSELECToperations，如果error-log中出現(xiàn)此報(bào)錯(cuò)，說(shuō)明select 操作使用了大的磁盤(pán)臨時(shí)表，不推薦啟用。
(小提示，客戶(hù)環(huán)境中時(shí)常會(huì)收到某張臨時(shí)表 #sql_tbl_name is full的告警郵件，需要考慮是否可以?xún)?yōu)化SQL了)
MTR 的執(zhí)行邏輯為啟動(dòng)一個(gè)臨時(shí) MySQL 服務(wù)，并執(zhí)行t目錄中 my0420.test 文件的內(nèi)容，執(zhí)行結(jié)果默認(rèn)會(huì)和r目錄中的 result 同名文件(也叫標(biāo)準(zhǔn)執(zhí)行結(jié)果文件，一般會(huì)在正確的版本中生成)進(jìn)行對(duì)比，用于判斷測(cè)試文件是否正確。
在mysql-test目錄下：
./mtr my0420.test
--執(zhí)行到以下語(yǔ)句時(shí)報(bào)錯(cuò)--
SET GLOBAL innodb_limit_optimistic_insert_debug=2;
[100%] main.my0420 [ fail ]
Test ended at 2022-04-20 20:05:39
CURRENT_TEST: main.my0420
mysqltest: At line 32: query 'select * from t1 order by func1(a)' failed: 2013: Lost connection to MySQL server during query
safe_process[7080]: Child process: 7081, exit: 1
Server [mysqld.1 - pid: 7089, winpid: 7089, exit: 256] failed during test run
Server log from this test:
Lost connection ，MySQL 服務(wù)已停止。之后打印了 error 信息。錯(cuò)誤同樣出現(xiàn)在 btr0btr.cc line 2165
Server log from this test:
----------SERVER LOG START-----------
2022-04-20T12:02:42.082135Z 0 [Note] /tools/mysql-test5.7.30/bin/mysqld (mysqld 5.7.30-debug-log) starting as process 7049 ...
2022-04-20T12:02:43.698812Z 0 [Note] /tools/mysql-test5.7.30/bin/mysqld: Shutdown complete
2022-04-20T12:02:45.051667Z 0 [Note] /tools/mysql-test5.7.30/bin/mysqld (mysqld 5.7.30-debug-log) starting as process 7090 ...
2022-04-20T12:02:45.262573Z 0 [Note] /tools/mysql-test5.7.30/bin/mysqld: ready for connections.
Version: '5.7.30-debug-log' socket: '/tools/mysql-test5.7.30/mysql-test/var/tmp/mysqld.1.sock' port: 13000 Source distribution
2022-04-20 15:05:37 0x7fc298bc4700 InnoDB: Assertion failure in thread 140473762858752 in file btr0btr.cc line 2165
InnoDB: Failing assertion: err==DB_SUCCESS
InnoDB: We intentionally generate a memory trap.
InnoDB: Submit a detailed bug report to http://bugs.mysql.com.
InnoDB: If you get repeated assertion failures or crashes, even
InnoDB: immediately after the mysqld startup, there may be
InnoDB: corruption in the InnoDB tablespace. Please refer to
InnoDB: http://dev.mysql.com/doc/refman/5.7/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
12:05:37 UTC - mysqld got signal 6 ;
This could be because you hit a bug. It is also possible that this binary
or one of the libraries it was linked against is corrupt, improperly built,
or misconfigured. This error can also be caused by malfunctioning hardware.
Attempting to collect some information that could help diagnose the problem.
As this is a crash and something is definitely wrong, the information
collection process might fail.
key_buffer_size=1048576
read_buffer_size=131072
max_used_connections=1
max_threads=151
thread_count=1
connection_count=1
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads=61093 K bytes of memory
Hope that's ok; if not, decrease some variables in the equation.
Trying to get some variables.
Some pointers may be invalid and cause the dump to abort.
Query (7fc234005890): select * from t1 order by func1(a)
Connection ID (thread ID): 2
Status: NOT_KILLED
和客戶(hù)環(huán)境的區(qū)別之處:
生產(chǎn)中的報(bào)錯(cuò)為 Query(7f3be00479d0) is an invalid pointer. 無(wú)效指針，類(lèi)似磁盤(pán)空間不足的報(bào)錯(cuò).
測(cè)試中的報(bào)錯(cuò)為 Query (7fc234005890): select * from t1 order by func1(a).
測(cè)試環(huán)境的堆棧信息:
https://github.com/mysql/mysql-server/blob/mysql-5.7.30/storage/innobase/btr/btr0btr.cc#L2285
（上圖中文是翻譯的代碼注釋?zhuān)赡軙?huì)有些偏差錯(cuò)誤）
檢查測(cè)試日志文件 error-log，默認(rèn)會(huì)在當(dāng)前目錄生成var目錄，其中包含 my.cnf 文件
/tools/mysql-test5.7.30/mysql-test/var/log/mysqld.1.err
Trying to get some variables.
Some pointers may be invalid and cause the dump to abort.
Query (7fc234005890): select * from t1 order by func1(a)
Connection ID (thread ID): 2
Status: NOT_KILLED
The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains
information that should help you find out what is causing the crash.
Writing a core file
safe_process[7089]: Child process: 7090, killed by signal: 6
關(guān)于編譯安裝 MySQL 的補(bǔ)充：
Cmake 編譯之后會(huì)在 DCMAKE_INSTALL_PREFIX 目錄中生成 mysql-test 測(cè)試框架目錄，
不需要以下步驟（以下步驟在不需要 DEBUG 調(diào)試時(shí)使用）
1.此包是mysql-test-5.7.30-linux-glibc2.12-x86_64.tar.gz
mv mysql-5.7.30-linux-glibc2.12-x86_64/ /tools/mysql-test
2.將mysql安裝包目錄下的文件與mtr目錄合并，mysql安裝包目錄下為basedir
cp -r /data/mysql/base/5.7.30 /tools/mysql-test
(插播生活日記，make命令大約需要執(zhí)行1個(gè)小時(shí)，剛好18:27，又恰逢隔離，起身洗鍋炸廚房了嗷)
此 BUG 可能會(huì)出現(xiàn)在 MySQL5.7 版本中
1.測(cè)試中驗(yàn)證了數(shù)據(jù)庫(kù)參數(shù) innodb_temp_data_file_path 增大max_file_size后不會(huì)發(fā)生服務(wù)崩潰，如果業(yè)務(wù) SQL 無(wú)法進(jìn)行優(yōu)化時(shí)，可以增大此參數(shù)，可降低觸發(fā)崩潰的概率。
2.測(cè)試中驗(yàn)證了數(shù)據(jù)庫(kù)參數(shù) internal_tmp_disk_storage_engine=MYISAM 時(shí)不會(huì)發(fā)生服務(wù)崩潰，默認(rèn) INNODB
如果業(yè)務(wù)無(wú)法升級(jí)到 8.0 時(shí)，可以動(dòng)態(tài)調(diào)整此參數(shù)。
我們建議的變更順序是:
優(yōu)化 SQL 語(yǔ)句 -> 增大 innodb_temp_data_file_path 參數(shù)的 max_file_size 值 -> 升級(jí)到 MySQL 8.0（使用會(huì)話臨時(shí)表空間） -> 修改 internal_tmp_disk_storage_engine 參數(shù)。
其中 internal_tmp_disk_storage_engine 參數(shù)，個(gè)人不是很理解，是否真的要將默認(rèn)值 INNODB 更改為 MYISAM 。之后請(qǐng)教同事了解到，"內(nèi)部臨時(shí)表不會(huì)被復(fù)制，不會(huì)有并發(fā)訪問(wèn)，是可以考慮使用 MYISAM 的"
再次感謝嗷。
BUG報(bào)告:
https://bugs.mysql.com/bug.php?id=101154 https://jira.percona.com/browse/PS-7318?focusedCommentId=268045&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-268045
編譯安裝及參數(shù)說(shuō)明:
https://blog.csdn.net/iteye_621/article/details/81959655 https://baijiahao.baidu.com/s?id=1725289345179642059&wfr=spider&for=pc
https://dev.mysql.com/doc/refman/5.7/en/source-configuration-options.html#cmake-general-options
MTR 文檔:
https://dev.mysql.com/doc/dev/mysql-server/latest/PAGE_MYSQLTEST_FRAMEWORK_COMPONENTS.html
數(shù)據(jù)庫(kù)參數(shù):
https://dev.mysql.com/doc/refman/5.7/en/server-status-variables.html#statvar_Created_tmp_tables
https://dev.mysql.com/doc/refman/5.7/en/server-status-variables.html#statvar_Created_tmp_disk_tables
https://dev.mysql.com/doc/refman/5.7/en/server-system-variables.html#sysvar_tmp_table_size
https://dev.mysql.com/doc/refman/5.7/en/server-system-variables.html#sysvar_max_heap_table_size
https://dev.mysql.com/doc/refman/5.7/en/server-system-variables.html#sysvar_big_tables
https://dev.mysql.com/doc/refman/5.7/en/select.html