摘要:實際應(yīng)用中,查詢的返回結(jié)果會有條記錄。修改保存文件后,重啟服務(wù)。通常優(yōu)化至少到級別,最好能優(yōu)化到指出使用哪個索引在該表找到行記錄。如果該值為,說明沒有使用索引,可以建立索引提高性能顯示實際使用的索引。
最近公司項目添加新功能,上線后發(fā)現(xiàn)有些功能的列表查詢時間很久。原因是新功能用到舊功能的接口,而這些舊接口的 SQL 查詢語句關(guān)聯(lián)5,6張表且編寫不夠規(guī)范,導(dǎo)致 MySQL 在執(zhí)行 SQL 語句時索引失效,進(jìn)行全表掃描。原本負(fù)責(zé)優(yōu)化的同事有事請假回家,因此優(yōu)化查詢數(shù)據(jù)的問題落在筆者手中。筆者在查閱網(wǎng)上 SQL 優(yōu)化的資料后成功解決了問題,在此從全局角度記錄和總結(jié) MySQL 查詢優(yōu)化相關(guān)技巧。
數(shù)據(jù)查詢慢,不代表 SQL 語句寫法有問題。?首先,我們需要找到問題的源頭才能“對癥下藥”。筆者用一張流程圖展示 MySQL 優(yōu)化的思路:
無需更多言語,從圖中可以清楚地看出,導(dǎo)致數(shù)據(jù)查詢慢的原因有多種,如:緩存失效,在此一段時間內(nèi)由于高并發(fā)訪問導(dǎo)致 MySQL 服務(wù)器崩潰;SQL 語句編寫問題;MySQL 服務(wù)器參數(shù)問題;硬件配置限制 MySQL 服務(wù)性能問題等。
如果系統(tǒng)的并發(fā)請求數(shù)不高,且查詢速度慢,可以忽略該步驟直接進(jìn)行 SQL 語句調(diào)優(yōu)步驟。
執(zhí)行命令:
show status
由于返回結(jié)果太多,此處不貼出結(jié)果。其中,再返回的結(jié)果中,我們主要關(guān)注 “Queries”、“Threads_connected” 和 “Threads_running” 的值,即查詢次數(shù)、線程連接數(shù)和線程運行數(shù)。
我們可以通過執(zhí)行如下腳本監(jiān)控 MySQL 服務(wù)器運行的狀態(tài)值
#!/bin/bashwhile truedomysqladmin -uroot -p"密碼" ext | awk "/Queries/{q=$4}/Threads_connected/{c=$4}/Threads_running/{r=$4}END{printf("%d %d %d/n",q,c,r)}" >> status.txtsleep 1done
執(zhí)行該腳本 24 小時,獲取 status.txt 里的內(nèi)容,再次通過 awk 計算每秒請求 MySQL 服務(wù)的次數(shù)
awk "{q=$1-last;last=$1}{printf("%d %d %d/n",q,$2,$3)}" status.txt
復(fù)制計算好的內(nèi)容到 Excel 中生成圖表觀察數(shù)據(jù)周期性。
如果觀察的數(shù)據(jù)有周期性的變化,如上圖的解釋,需要修改緩存失效策略。
例如:
通過隨機(jī)數(shù)在[3,6,9] 區(qū)間獲取其中一個值作為緩存失效時間,這樣分散了緩存失效時間,從而節(jié)省了一部分內(nèi)存的消耗。
當(dāng)訪問高峰期時,一部分請求分流到未失效的緩存,另一部分則訪問 MySQL 數(shù)據(jù)庫,這樣減少了 MySQL 服務(wù)器的壓力。
###?4.1 方式一:查看運行的線程
執(zhí)行命令:
show processlist
返回結(jié)果:
mysql> show processlist;+----+------+-----------+------+---------+------+----------+------------------+| Id | User | Host | db | Command | Time | State | Info |+----+------+-----------+------+---------+------+----------+------------------+| 9 | root | localhost | test | Query | 0 | starting | show processlist |+----+------+-----------+------+---------+------+----------+------------------+1 row in set (0.00 sec)
從返回結(jié)果中我們可以了解該線程執(zhí)行了什么命令/SQL 語句以及執(zhí)行的時間。實際應(yīng)用中,查詢的返回結(jié)果會有 N 條記錄。
其中,返回的 State 的值是我們判斷性能好壞的關(guān)鍵,其值出現(xiàn)如下內(nèi)容,則該行記錄的 SQL 語句需要優(yōu)化:
Converting HEAP to MyISAM # 查詢結(jié)果太大時,把結(jié)果放到磁盤,嚴(yán)重Create tmp table #創(chuàng)建臨時表,嚴(yán)重Copying to tmp table on disk #把內(nèi)存臨時表復(fù)制到磁盤,嚴(yán)重locked #被其他查詢鎖住,嚴(yán)重loggin slow query #記錄慢查詢Sorting result #排序
State 字段有很多值,如需了解更多,可以參看文章末尾提供的鏈接。
###?4.2 方式二:開啟慢查詢?nèi)罩?/p>
在配置文件 my.cnf 中的 [mysqld] 一行下邊添加兩個參數(shù):
slow_query_log = 1slow_query_log_file=/var/lib/mysql/slow-query.loglong_query_time = 2log_queries_not_using_indexes = 1
其中,slow_query_log = 1 表示開啟慢查詢;
slow_query_log_file 表示慢查詢?nèi)罩敬娣诺奈恢茫?/p>
long_query_time = 2 表示查詢 >=2 秒才記錄日志;
log_queries_not_using_indexes = 1 記錄沒有使用索引的 SQL 語句。
注意:slow_query_log_file 的路徑不能隨便寫,否則 MySQL 服務(wù)器可能沒有權(quán)限將日志文件寫到指定的目錄中。建議直接復(fù)制上文的路徑。
修改保存文件后,重啟 MySQL 服務(wù)。在 /var/lib/mysql/ 目錄下會創(chuàng)建 slow-query.log 日志文件。連接 MySQL 服務(wù)端執(zhí)行如下命令可以查看配置情況。
show variables like "slow_query%";show variables like "long_query_time";
測試慢查詢?nèi)罩荆?/p>
mysql> select sleep(2);+----------+| sleep(2) |+----------+| 0 |+----------+1 row in set (2.00 sec)
打開慢查詢?nèi)罩疚募?/p>
[root@localhost mysql]# vim /var/lib/mysql/slow-query.log/usr/sbin/mysqld, Version: 5.7.19-log (MySQL Community Server (GPL)). started with:Tcp port: 0 Unix socket: /var/lib/mysql/mysql.sockTime Id Command Argument# Time: 2017-10-05T04:39:11.408964Z# User@Host: root[root] @ localhost [] Id: 3# Query_time: 2.001395 Lock_time: 0.000000 Rows_sent: 1 Rows_examined: 0use test;SET timestamp=1507178351;select sleep(2);
我們可以看到剛才執(zhí)行了 2 秒的 SQL 語句被記錄下來了。
雖然在慢查詢?nèi)罩局杏涗洸樵兟?SQL 信息,但是日志記錄的內(nèi)容密集且不易查閱。因此,我們需要通過工具將 SQL 篩選出來。
MySQL 提供 mysqldumpslow 工具對日志進(jìn)行分析。我們可以使用 mysqldumpslow --help 查看命令相關(guān)用法。
常用參數(shù)如下:
-s:排序方式,后邊接著如下參數(shù) c:訪問次數(shù) l:鎖定時間 r:返回記錄 t:查詢時間 al:平均鎖定時間 ar:平均返回記錄書 at:平均查詢時間 -t:返回前面多少條的數(shù)據(jù) -g:翻遍搭配一個正則表達(dá)式,大小寫不敏感
案例:
獲取返回記錄集最多的10個sqlmysqldumpslow -s r -t 10 /var/lib/mysql/slow-query.log獲取訪問次數(shù)最多的10個sqlmysqldumpslow -s c -t 10 /var/lib/mysql/slow-query.log獲取按照時間排序的前10條里面含有左連接的查詢語句mysqldumpslow -s t -t 10 -g "left join" /var/lib/mysql/slow-query.log
篩選出有問題的 SQL,我們可以使用 MySQL 提供的 explain 查看 SQL 執(zhí)行計劃情況(關(guān)聯(lián)表,表查詢順序、索引使用情況等)。
用法:
explain select * from category;
返回結(jié)果:
mysql> explain select * from category;+----+-------------+----------+------------+------+---------------+------+---------+------+------+----------+-------+| id | select_type | table | partitions | type | possible_keys | key | key_len | ref | rows | filtered | Extra |+----+-------------+----------+------------+------+---------------+------+---------+------+------+----------+-------+| 1 | SIMPLE | category | NULL | ALL | NULL | NULL | NULL | NULL | 1 | 100.00 | NULL |+----+-------------+----------+------------+------+---------------+------+---------+------+------+----------+-------+1 row in set, 1 warning (0.00 sec)
字段解釋:
1. id:select 查詢序列號。id相同,執(zhí)行順序由上至下;id不同,id值越大優(yōu)先級越高,越先被執(zhí)行
2. select_type:查詢數(shù)據(jù)的操作類型,其值如下:
simple:簡單查詢,不包含子查詢或 unionprimary:包含復(fù)雜的子查詢,最外層查詢標(biāo)記為該值subquery:在 select 或 where 包含子查詢,被標(biāo)記為該值derived:在 from 列表中包含的子查詢被標(biāo)記為該值,MySQL 會遞歸執(zhí)行這些子查詢,把結(jié)果放在臨時表union:若第二個 select 出現(xiàn)在 union 之后,則被標(biāo)記為該值。若 union 包含在 from 的子查詢中,外層 select 被標(biāo)記為 derived union result:從 union 表獲取結(jié)果的 select
3. table:顯示該行數(shù)據(jù)是關(guān)于哪張表
4. partitions:匹配的分區(qū)
5. type:表的連接類型,其值,性能由高到底排列如下:
system:表只有一行記錄,相當(dāng)于系統(tǒng)表const:通過索引一次就找到,只匹配一行數(shù)據(jù)eq_ref:唯一性索引掃描,對于每個索引鍵,表中只有一條記錄與之匹配。常用于主鍵或唯一索引掃描ref:非唯一性索引掃描,返回匹配某個多帶帶值的所有行。用于=、< 或 > 操作符帶索引的列range:只檢索給定范圍的行,使用一個索引來選擇行。一般使用between、>、<情況index:只遍歷索引樹ALL:全表掃描,性能最差
注:前5種情況都是理想情況的索引使用情況。通常優(yōu)化至少到range級別,最好能優(yōu)化到 ref
6. possible_keys:指出 MySQL 使用哪個索引在該表找到行記錄。如果該值為 NULL,說明沒有使用索引,可以建立索引提高性能
7. key:顯示 MySQL 實際使用的索引。如果為 NULL,則沒有使用索引查詢
8. key_len:表示索引中使用的字節(jié)數(shù),通過該列計算查詢中使用的索引的長度。在不損失精確性的情況下,長度越短越好 顯示的是索引字段的最大長度,并非實際使用長度
9. ref:顯示該表的索引字段關(guān)聯(lián)了哪張表的哪個字段
10. rows:根據(jù)表統(tǒng)計信息及選用情況,大致估算出找到所需的記錄或所需讀取的行數(shù),數(shù)值越小越好
11. filtered:返回結(jié)果的行數(shù)占讀取行數(shù)的百分比,值越大越好
12. extra: 包含不合適在其他列中顯示但十分重要的額外信息,常見的值如下:
using filesort:說明 MySQL 會對數(shù)據(jù)使用一個外部的索引排序,而不是按照表內(nèi)的索引順序進(jìn)行讀取。出現(xiàn)該值,應(yīng)該優(yōu)化 SQLusing temporary:使用了臨時表保存中間結(jié)果,MySQL 在對查詢結(jié)果排序時使用臨時表。常見于排序 order by 和分組查詢 group by。出現(xiàn)該值,應(yīng)該優(yōu)化 SQL using index:表示相應(yīng)的 select 操作使用了覆蓋索引,避免了訪問表的數(shù)據(jù)行,效率不錯using where:where 子句用于限制哪一行using join buffer:使用連接緩存distinct:發(fā)現(xiàn)第一個匹配后,停止為當(dāng)前的行組合搜索更多的行
注意:出現(xiàn)前 2 個值,SQL 語句必須要優(yōu)化。
使用 profiling 命令可以了解 SQL 語句消耗資源的詳細(xì)信息(每個執(zhí)行步驟的開銷)。
select @@profiling;
返回結(jié)果:
mysql> select @@profiling;+-------------+| @@profiling |+-------------+| 0 |+-------------+1 row in set, 1 warning (0.00 sec)
0 表示關(guān)閉狀態(tài),1 表示開啟
set profiling = 1;
返回結(jié)果:
mysql> set profiling = 1; Query OK, 0 rows affected, 1 warning (0.00 sec)mysql> select @@profiling;+-------------+| @@profiling |+-------------+| 1 |+-------------+1 row in set, 1 warning (0.00 sec)
在連接關(guān)閉后,profiling 狀態(tài)自動設(shè)置為關(guān)閉狀態(tài)。
show profiles;
返回結(jié)果:
mysql> show profiles;+----------+------------+------------------------------+| Query_ID | Duration | Query |+----------+------------+------------------------------+| 1 | 0.00062925 | select @@profiling || 2 | 0.00094150 | show tables || 3 | 0.00119125 | show databases || 4 | 0.00029750 | SELECT DATABASE() || 5 | 0.00025975 | show databases || 6 | 0.00023050 | show tables || 7 | 0.00042000 | show tables || 8 | 0.00260675 | desc role || 9 | 0.00074900 | select name,is_key from role |+----------+------------+------------------------------+9 rows in set, 1 warning (0.00 sec)
該命令執(zhí)行之前,需要執(zhí)行其他 SQL 語句才有記錄。
show profile for query Query_ID;
返回結(jié)果:
mysql> show profile for query 9;+----------------------+----------+| Status | Duration |+----------------------+----------+| starting | 0.000207 || checking permissions | 0.000010 || Opening tables | 0.000042 || init | 0.000050 || System lock | 0.000012 || optimizing | 0.000003 || statistics | 0.000011 || preparing | 0.000011 || executing | 0.000002 || Sending data | 0.000362 || end | 0.000006 || query end | 0.000006 || closing tables | 0.000006 || freeing items | 0.000011 || cleaning up | 0.000013 |+----------------------+----------+15 rows in set, 1 warning (0.00 sec)
每行都是狀態(tài)變化的過程以及它們持續(xù)的時間。Status 這一列和 show processlist 的 State 是一致的。因此,需要優(yōu)化的注意點與上文描述的一樣。
其中,Status 字段的值同樣可以參考末尾鏈接。
show profile block io,cpu for query Query_ID;show profile cpu,block io,memory,swaps,context switches,source for query Query_ID;show profile all for query Query_ID;
主要以查詢優(yōu)化、索引使用和表結(jié)構(gòu)設(shè)計方面進(jìn)行講解。
避免 SELECT *,需要什么數(shù)據(jù),就查詢對應(yīng)的字段。
小表驅(qū)動大表,即小的數(shù)據(jù)集驅(qū)動大的數(shù)據(jù)集。如:以 A,B 兩表為例,兩表通過 id 字段進(jìn)行關(guān)聯(lián)。
當(dāng) B 表的數(shù)據(jù)集小于 A 表時,用 in 優(yōu)化 exist;使用 in ,兩表執(zhí)行順序是先查 B 表,再查 A 表select * from A where id in (select id from B)當(dāng) A 表的數(shù)據(jù)集小于 B 表時,用 exist 優(yōu)化 in;使用 exists,兩表執(zhí)行順序是先查 A 表,再查 B 表select * from A where exists (select 1 from B where B.id = A.id)
一些情況下,可以使用連接代替子查詢,因為使用 join,MySQL 不會在內(nèi)存中創(chuàng)建臨時表。
適當(dāng)添加冗余字段,減少表關(guān)聯(lián)。
合理使用索引(下文介紹)。如:為排序、分組字段建立索引,避免 filesort 的出現(xiàn)。
主鍵自動創(chuàng)建唯一索引
頻繁作為查詢條件的字段
查詢中與其他表關(guān)聯(lián)的字段
查詢中排序的字段
查詢中統(tǒng)計或分組字段
頻繁更新的字段
where 條件中用不到的字段
表記錄太少
經(jīng)常增刪改的表
字段的值的差異性不大或重復(fù)性高
單表查詢:哪個列作查詢條件,就在該列創(chuàng)建索引
多表查詢:left join 時,索引添加到右表關(guān)聯(lián)字段;right join 時,索引添加到左表關(guān)聯(lián)字段
不要對索引列進(jìn)行任何操作(計算、函數(shù)、類型轉(zhuǎn)換)
索引列中不要使用 !=,<> 非等于
索引列不要為空,且不要使用 is null 或 is not null 判斷
索引字段是字符串類型,查詢條件的值要加’"單引號,避免底層類型自動轉(zhuǎn)換
違背上述原則可能會導(dǎo)致索引失效,具體情況需要使用 explain 命令進(jìn)行查看
除了違背索引創(chuàng)建和使用原則外,如下情況也會導(dǎo)致索引失效:
模糊查詢時,以 % 開頭
使用 or 時,如:字段1(非索引)or 字段2(索引)會導(dǎo)致索引失效。
使用復(fù)合索引時,不使用第一個索引列。
index(a,b,c) ,以字段 a,b,c 作為復(fù)合索引為例:
語句 | 索引是否生效 |
---|---|
where a = 1 | 是,字段 a 索引生效 |
where a = 1 and b = 2 | 是,字段 a 和 b 索引生效 |
where a = 1 and b = 2 and c = 3 | 是,全部生效 |
where b = 2 或 where c = 3 | 否 |
where a = 1 and c = 3 | 字段 a 生效,字段 c 失效 |
where a = 1 and b > 2 and c = 3 | 字段 a,b 生效,字段 c 失效 |
where a = 1 and b like ‘xxx%’ and c = 3 | 字段 a,b 生效,字段 c 失效 |
使用可以存下數(shù)據(jù)最小的數(shù)據(jù)類型
使用簡單的數(shù)據(jù)類型。int 要比 varchar 類型在mysql處理簡單
盡量使用 tinyint、smallint、mediumint 作為整數(shù)類型而非 int
盡可能使用 not null 定義字段,因為 null 占用4字節(jié)空間
盡量少用 text 類型,非用不可時最好考慮分表
盡量使用 timestamp 而非 datetime
單表不要有太多字段,建議在 20 以內(nèi)
當(dāng)數(shù)據(jù)庫中的數(shù)據(jù)非常大時,查詢優(yōu)化方案也不能解決查詢速度慢的問題時,我們可以考慮拆分表,讓每張表的數(shù)據(jù)量變小,從而提高查詢效率。
1. 垂直拆分:將表中多個列分開放到不同的表中。例如用戶表中一些字段經(jīng)常被訪問,將這些字段放在一張表中,另外一些不常用的字段放在另一張表中。 插入數(shù)據(jù)時,使用事務(wù)確保兩張表的數(shù)據(jù)一致性。
2. 水平拆分:按照行進(jìn)行拆分。例如用戶表中,使用用戶ID,對用戶ID取10的余數(shù),將用戶數(shù)據(jù)均勻的分配到0~9的10個用戶表中。查找時也按照這個規(guī)則查詢數(shù)據(jù)。
一般情況下對數(shù)據(jù)庫而言都是“讀多寫少”。換言之,數(shù)據(jù)庫的壓力多數(shù)是因為大量的讀取數(shù)據(jù)的操作造成的。我們可以采用數(shù)據(jù)庫集群的方案,使用一個庫作為主庫,負(fù)責(zé)寫入數(shù)據(jù);其他庫為從庫,負(fù)責(zé)讀取數(shù)據(jù)。這樣可以緩解對數(shù)據(jù)庫的訪問壓力。
sort_buffer_size 排序緩沖區(qū)內(nèi)存大小
join_buffer_size 使用連接緩沖區(qū)大小
read_buffer_size 全表掃描時分配的緩沖區(qū)大小
Innodb_log_file_size 事務(wù)日志大小
Innodb_log_files_in_group 事務(wù)日志個數(shù)
Innodb_log_buffer_size 事務(wù)日志緩沖區(qū)大小
Innodb_flush_log_at_trx_commit 事務(wù)日志刷新策略,其值如下:
0:每秒進(jìn)行一次 log 寫入 cache,并 flush log 到磁盤
1:在每次事務(wù)提交執(zhí)行 log 寫入 cache,并 flush log 到磁盤
2:每次事務(wù)提交,執(zhí)行 log 數(shù)據(jù)寫到 cache,每秒執(zhí)行一次 flush log 到磁盤
expire_logs_days 指定自動清理 binlog 的天數(shù)
max_allowed_packet 控制 MySQL 可以接收的包的大小
skip_name_resolve 禁用 DNS 查找
read_only 禁止非 super 權(quán)限用戶寫權(quán)限
skip_slave_start 級你用 slave 自動恢復(fù)
###?7.4 其他
max_connections 控制允許的最大連接數(shù)
tmp_table_size 臨時表大小
max_heap_table_size 最大內(nèi)存表大小
筆者并沒有使用這些參數(shù)對 MySQL 服務(wù)器進(jìn)行調(diào)優(yōu),具體詳情介紹和性能效果請參考文章末尾的資料或另行百度。
硬件的性能直接決定 MySQL 數(shù)據(jù)庫的性能瓶頸,直接決定 MySQL 數(shù)據(jù)庫的運行數(shù)據(jù)和效率。
作為軟件開發(fā)程序員,我們主要關(guān)注軟件方面的優(yōu)化內(nèi)容,以下硬件方面的優(yōu)化作為了解即可
內(nèi)存的 IO 比硬盤的速度快很多,可以增加系統(tǒng)的緩沖區(qū)容量,使數(shù)據(jù)在內(nèi)存停留的時間更長,以減少磁盤的 IO
使用 SSD 或 PCle SSD 設(shè)備,至少獲得數(shù)百倍甚至萬倍的 IOPS 提升
購置陣列卡同時配備 CACHE 及 BBU 模塊,可以明顯提升 IOPS
盡可能選用 RAID-10,而非 RAID-5
###?8.3 配置 CUP 相關(guān)
在服務(wù)器的 BIOS 設(shè)置中,調(diào)整如下配置:
選擇 Performance Per Watt Optimized(DAPC)模式,發(fā)揮 CPU 最大性能
關(guān)閉 C1E 和 C States 等選項,提升 CPU 效率
Memory Frequency(內(nèi)存頻率)選擇 Maximum Performance
文章版權(quán)歸作者所有,未經(jīng)允許請勿轉(zhuǎn)載,若此文章存在違規(guī)行為,您可以聯(lián)系管理員刪除。
轉(zhuǎn)載請注明本文地址:http://m.specialneedsforspecialkids.com/yun/119540.html
摘要:作為面試官,我是如何甄別應(yīng)聘者的包裝程度語言和等其他語言的對比分析和主從復(fù)制的原理詳解和持久化的原理是什么面試中經(jīng)常被問到的持久化與恢復(fù)實現(xiàn)故障恢復(fù)自動化詳解哨兵技術(shù)查漏補(bǔ)缺最易錯過的技術(shù)要點大掃盲意外宕機(jī)不難解決,但你真的懂?dāng)?shù)據(jù)恢復(fù)嗎每秒 作為面試官,我是如何甄別應(yīng)聘者的包裝程度Go語言和Java、python等其他語言的對比分析 Redis和MySQL Redis:主從復(fù)制的原理詳...
摘要:作為面試官,我是如何甄別應(yīng)聘者的包裝程度語言和等其他語言的對比分析和主從復(fù)制的原理詳解和持久化的原理是什么面試中經(jīng)常被問到的持久化與恢復(fù)實現(xiàn)故障恢復(fù)自動化詳解哨兵技術(shù)查漏補(bǔ)缺最易錯過的技術(shù)要點大掃盲意外宕機(jī)不難解決,但你真的懂?dāng)?shù)據(jù)恢復(fù)嗎每秒 作為面試官,我是如何甄別應(yīng)聘者的包裝程度Go語言和Java、python等其他語言的對比分析 Redis和MySQL Redis:主從復(fù)制的原理詳...
摘要:讓你收獲滿滿碼個蛋從年月日推送第篇文章一年過去了已累積推文近篇文章,本文為年度精選,共計篇,按照類別整理便于讀者主題閱讀。本篇文章是今年的最后一篇技術(shù)文章,為了讓大家在家也能好好學(xué)習(xí),特此花了幾個小時整理了這些文章。 showImg(https://segmentfault.com/img/remote/1460000013241596); 讓你收獲滿滿! 碼個蛋從2017年02月20...
閱讀 3465·2021-09-08 09:36
閱讀 2555·2019-08-30 15:54
閱讀 2355·2019-08-30 15:54
閱讀 1768·2019-08-30 15:44
閱讀 2391·2019-08-26 14:04
閱讀 2444·2019-08-26 14:01
閱讀 2880·2019-08-26 13:58
閱讀 1330·2019-08-26 13:47