慢SQL優(yōu)化的常用方法

（1）建立物化視圖或盡可能減少多表查詢(xún)。（2）以不相干子查詢(xún)替代相干子查詢(xún)。（3）只檢索需要的列。（4）用帶in的條件子句等價(jià)替換or子句。（5）經(jīng)常提交commit，以盡早釋放鎖。（6）避免嵌套的游標(biāo)（Cursor）和多重循環(huán)等。（7）在經(jīng)常查詢(xún)的列上創(chuàng)建索引，提高查詢(xún)效率。（8）避免使用模糊查詢(xún)進(jìn)行匹配，如果一定要使用，建議使用最左模糊匹配原則。（9）慢的查詢(xún)的sql，根據(jù)性能和存儲(chǔ)容量大小進(jìn)行評(píng)估，適當(dāng)?shù)目梢钥紤]水平分表和垂直分表，以提高sql的查詢(xún)性能。（10）查詢(xún)數(shù)據(jù)是否存在，適當(dāng)?shù)目梢允褂胑xists替代in。建表1.盡量使用數(shù)字型字段，若只含數(shù)值信息的字段盡量不要設(shè)計(jì)為字符型，這會(huì)降低查詢(xún)和連接的性能，并會(huì)增加存儲(chǔ)開(kāi)銷(xiāo)。這是因?yàn)橐嬖谔幚聿樵?xún)和連 接時(shí)會(huì)逐個(gè)比較字符串中每一個(gè)字符，而對(duì)于數(shù)字型而言只需要比較一次就夠了。2.盡可能的使用 varchar 代替 char ，因?yàn)槭紫茸冮L(zhǎng)字段存儲(chǔ)空間小，可以節(jié)省存儲(chǔ)空間， 其次對(duì)于查詢(xún)來(lái)說(shuō)，在一個(gè)相對(duì)較小的字段內(nèi)搜索效率顯然要高些。臨時(shí)表避免頻繁創(chuàng)建和刪除臨時(shí)表，以減少系統(tǒng)表資源的消耗盡量使用表變量來(lái)代替臨時(shí)表。如果表變量包含大量數(shù)據(jù)，請(qǐng)注意索引非常有限（只有主鍵索引）。臨時(shí)表并不是不可使用，適當(dāng)?shù)厥褂盟鼈兛梢允鼓承├谈行?，例如，?dāng)需要重復(fù)引用大型表或常用表中的某個(gè)數(shù)據(jù)集時(shí)。但是，對(duì)于一次性事件，最好使用導(dǎo)出表。在新建臨時(shí)表時(shí)，如果一次性插入數(shù)據(jù)量很大，那么可以使用 select into 代替 create table，避免造成大量 log，以提高速度；如果數(shù)據(jù)量不大，為了緩和系統(tǒng)表的資源，應(yīng)先create table，然后insert。如果使用到了臨時(shí)表，在存儲(chǔ)過(guò)程的最后務(wù)必將所有的臨時(shí)表顯式刪除，先 truncate table，然后 drop table，這樣可以避免系統(tǒng)表的較長(zhǎng)時(shí)間鎖定。游標(biāo)的問(wèn)題盡量避免使用游標(biāo)，因?yàn)橛螛?biāo)的效率較差，如果游標(biāo)操作的數(shù)據(jù)超過(guò)1萬(wàn)行，那么就應(yīng)該考慮改寫(xiě)。游標(biāo)的一個(gè)常見(jiàn)用途就是保存查詢(xún)結(jié)果，以便以后使用。游標(biāo)的結(jié)果集是由SELECT語(yǔ)句產(chǎn)生，如果處理過(guò)程需要重復(fù)使用一個(gè)記錄集，那么創(chuàng)建一次游標(biāo)而重復(fù)使用若干次，比重復(fù)查詢(xún)數(shù)據(jù)庫(kù)要快的多。使用基于游標(biāo)的方法或臨時(shí)表方法之前，應(yīng)先尋找基于集的解決方案來(lái)解決問(wèn)題，基于集的方法通常更有效。與臨時(shí)表一樣，游標(biāo)并不是不可使用。對(duì)小型數(shù)據(jù)集使用 FAST_FORWARD 游標(biāo)通常要優(yōu)于其他逐行處理方法，尤其是在必須引用幾個(gè)表才能獲得所需的數(shù)據(jù)時(shí)。在結(jié)果集中包括“合計(jì)”的例程通常要比使用游標(biāo)執(zhí)行的速度快。如果開(kāi)發(fā)時(shí)間允許，基于游標(biāo)的方法和基于集的方法都可以嘗試一下，看哪一種方法的效果更好。事務(wù)盡量避免大事務(wù)操作，提高系統(tǒng)并發(fā)能力。數(shù)據(jù)量問(wèn)題13.盡量避免向客戶(hù)端返回大數(shù)據(jù)量，若數(shù)據(jù)量過(guò)大，應(yīng)該考慮相應(yīng)需求是否合理。具體SQL優(yōu)化 1.避免使用select *select *不走覆蓋索引，會(huì)有大量的回表操作，從而導(dǎo)致查詢(xún)SQL的性能很低。應(yīng)該使用具體的字段代替*，只返回使用到的字段。     2.用union all代替unionunion可以獲取排除重復(fù)后的數(shù)據(jù)，union all可以獲取所有數(shù)據(jù)，包含重復(fù)的數(shù)據(jù)，排除重復(fù)的過(guò)程需要遍歷，排序和比較，他更耗時(shí)，更消耗CPU資源，所以如果能用union all，盡量不用union，除非是業(yè)務(wù)場(chǎng)景中不允許產(chǎn)生重復(fù)數(shù)據(jù)3.小表驅(qū)動(dòng)大表in 和 not in 也要慎用，否則會(huì)導(dǎo)致全表掃描。對(duì)于連續(xù)的數(shù)值，能用 between 就不要用 in，對(duì)于子查詢(xún)，可以用exists代替。用小表的數(shù)據(jù)集驅(qū)動(dòng)大表的數(shù)據(jù)集in關(guān)鍵字，他會(huì)優(yōu)先執(zhí)行in里面的子查詢(xún)語(yǔ)句，然后在執(zhí)行in外面的語(yǔ)句，in里面的數(shù)據(jù)量很少，作為條件查詢(xún)速度更快exists關(guān)鍵字，他會(huì)優(yōu)先執(zhí)行exists左邊的語(yǔ)句（即主查詢(xún)語(yǔ)句），然后把它作為條件，去跟右邊的語(yǔ)句匹配，如果匹配上，則可以查出數(shù)據(jù)，如果匹配不上，數(shù)據(jù)就被過(guò)濾掉了in適用于左邊大表，右邊小表exists適用于左邊小表，右邊大表4.批量操作每次遠(yuǎn)程請(qǐng)求數(shù)據(jù)庫(kù)，是會(huì)消耗一定性能的提供一個(gè)批量插入的方法，這樣只需要遠(yuǎn)程請(qǐng)求一次數(shù)據(jù)庫(kù)，SQL性能會(huì)提升，數(shù)據(jù)量越大，提升越多，但是不建議一次批量操作太多數(shù)據(jù)，如果數(shù)據(jù)太多，數(shù)據(jù)庫(kù)響應(yīng)也會(huì)很慢，批量操作需要把握一個(gè)度，建議每批數(shù)據(jù)盡量控制在500以?xún)?nèi)，多批如果數(shù)據(jù)多于500，則分多批處理。5.多用limit6.in中值太多如果in數(shù)據(jù)太多，不做任何限制，可能會(huì)導(dǎo)致接口超時(shí)可以在SQL語(yǔ)句中對(duì)數(shù)據(jù)用limit做限制，不過(guò)更多的是在業(yè)務(wù)代碼中加限制如果超出500，可以分批用多線(xiàn)程去查詢(xún)數(shù)據(jù)，每批只查500條記錄，最后把查詢(xún)到的數(shù)據(jù)匯總到一起返回7.增量查詢(xún)有時(shí)候，我們需要通過(guò)遠(yuǎn)程接口查詢(xún)數(shù)據(jù)，然后同步到另一個(gè)數(shù)據(jù)庫(kù)，如果直接獲取所有的數(shù)據(jù)，然后同步過(guò)去，這樣如果數(shù)據(jù)很多，查詢(xún)性能會(huì)非常差，可以按時(shí)間和id升序，每次只同步一批數(shù)據(jù)，這一批數(shù)據(jù)只有100條記錄，每次同步完后，保存這100條數(shù)據(jù)中最大的id和時(shí)間，給同步下一批數(shù)據(jù)的時(shí)候用，通過(guò)這種增量查詢(xún)的方式，能夠提升單次查詢(xún)的效率select * from user where id > #{lastId} and create_time >= #{lastCreateTime} limit 100;8.高效的分頁(yè)列表頁(yè)在查詢(xún)數(shù)據(jù)的時(shí)候，為了避免一次性返回過(guò)多的數(shù)據(jù)影響接口性能，我們一般會(huì)對(duì)查詢(xún)接口做分頁(yè)處理，在數(shù)據(jù)庫(kù)中分頁(yè)一般用的limit關(guān)鍵字如圖select id,name,age from user limit 10,20;如果表中的數(shù)據(jù)量較少，用limit關(guān)鍵字做分頁(yè)，沒(méi)什么問(wèn)題，但如果表中數(shù)據(jù)量很多，用他就會(huì)出現(xiàn)性能問(wèn)題，select id,name,age from user limit 1000000,20;優(yōu)化select id,name,age from user where id >1000000 limit 20;利用id上的索引查詢(xún)，要求id是連續(xù)的，并且是有序的，還可以使用between優(yōu)化分頁(yè)select id,name,age from user where id between 1000000 and  1000020;between要在唯一索引上分頁(yè)，不然會(huì)出現(xiàn)每頁(yè)大小不一致的問(wèn)題9.用連接查詢(xún)代替子查詢(xún)數(shù)據(jù)庫(kù)中如果需要從兩張以上的表中查詢(xún)出數(shù)據(jù)的話(huà)，一般有兩種方式，子查詢(xún)和連接查詢(xún)子查詢(xún)，可以通過(guò)in關(guān)鍵字實(shí)現(xiàn)，一個(gè)查詢(xún)語(yǔ)句的條件落在另一個(gè)select語(yǔ)句的查詢(xún)結(jié)果中，程序先運(yùn)行嵌套在最內(nèi)層的語(yǔ)句，在運(yùn)行外層的語(yǔ)句，子查詢(xún)的優(yōu)點(diǎn)是簡(jiǎn)單，結(jié)構(gòu)化，如果涉及的表數(shù)據(jù)不多的話(huà)，但缺點(diǎn)是數(shù)據(jù)庫(kù)執(zhí)行子查詢(xún)時(shí)，需要?jiǎng)?chuàng)建臨時(shí)表，查詢(xún)完畢后，會(huì)刪除這些臨時(shí)表，有一些額外的性能消耗select * from order where user_id in (select id from user where status=1);連接查詢(xún)，性能會(huì)更高select o.* from order oinner join user u on o.user_id=u.idwhere u.status=1;10.join的表不宜過(guò)多join表的數(shù)據(jù)不應(yīng)超過(guò)3個(gè)，如果join太多，數(shù)據(jù)庫(kù)在選擇索引的時(shí)候會(huì)非常復(fù)雜，很容易選錯(cuò)索引，并且如果每天命中，nested loop join就是分別從兩個(gè)表讀一行數(shù)據(jù)進(jìn)行兩兩對(duì)比11.join時(shí)要注意我們?cè)谑褂枚鄰埍砺?lián)合查詢(xún)的時(shí)候，一般會(huì)使用join關(guān)鍵字，join使用最多的是是left join和inner joinleft join求兩個(gè)表的交集外加左表剩下的數(shù)據(jù)inner join求兩個(gè)表交集的數(shù)據(jù)12.索引        并不是所有索引對(duì)查詢(xún)都有效，SQL是根據(jù)表中數(shù)據(jù)來(lái)進(jìn)行查詢(xún)優(yōu)化的，當(dāng)索引列有大量數(shù)據(jù)重復(fù)時(shí)，SQL查詢(xún)可能不會(huì)去利用索引，如一表中有字段sex，male、female幾乎各一半，那么即使在sex上建了索引也對(duì)查詢(xún)效率起不了作用。        索引問(wèn)題 法則：不要在建立的索引的數(shù)據(jù)列上進(jìn)行下列操作:避免對(duì)索引字段進(jìn)行計(jì)算操作。避免在索引字段上使用not，<>，!=。避免在索引列上使用IS NULL和IS NOT NULL。避免在索引列上出現(xiàn)數(shù)據(jù)類(lèi)型轉(zhuǎn)換。避免在索引字段上使用函數(shù)。避免建立索引的列中使用空值。        索引并不是越多越好，索引固然可以提高相應(yīng)的 select 的效率，但同時(shí)也降低了 insert 及 update 的效率， 因?yàn)?insert 或 update 時(shí)有可能會(huì)重建索引，所以怎樣建索引需要慎重考慮，視具體情況而定。一個(gè)表的索引數(shù)最好不要超過(guò)6個(gè)，若太多則應(yīng)考慮一些不常使用到的列上建的索引是否有必要。        在使用索引字段作為條件時(shí)，如果該索引是復(fù)合索引，那么必須使用到該索引中的第一個(gè)字段作為條件時(shí)才能保證系統(tǒng)使用該索引，否則該索引將不會(huì)被使用，并且應(yīng)盡可能的讓字段順序與索引順序相一致?？刂扑饕臄?shù)量：索引可以顯著提升 查詢(xún)的性能，但索引數(shù)量并非越多越好，因?yàn)楸碇行略鰯?shù)據(jù)時(shí)，需要同時(shí)為他創(chuàng)建索引，而索引時(shí)需要額外的存儲(chǔ)空間的，而且還會(huì)有一定的性能消耗，單表中的索引數(shù)量應(yīng)該盡量控制在5個(gè)以?xún)?nèi)，并且單個(gè)索引中的字段不超過(guò)5個(gè)13.合理的數(shù)據(jù)類(lèi)型14.提升group by的效率select user_id,user_name from order group by user_id having user_id <=200;優(yōu)化select user_id,user_name from order where user_id <=200 group by user_id;15，索引優(yōu)化檢查SQL語(yǔ)句有沒(méi)有走索引-explain查看數(shù)據(jù)庫(kù)的執(zhí)行計(jì)劃16.對(duì)查詢(xún)進(jìn)行優(yōu)化，應(yīng)盡量避免全表掃描，首先應(yīng)考慮在 where 及 order by 涉及的列上建立索引。where 表之間的連接必須寫(xiě)在其他 Where 條件之前， 那些可以過(guò)濾掉最大數(shù)量記錄的條件必須寫(xiě)在 Where 子句的末尾，HAVING 最后。不要在where條件中使用左右兩邊都是%的like模糊查詢(xún)，這樣會(huì)導(dǎo)致數(shù)據(jù)庫(kù)引擎放棄索引進(jìn)行全表掃描。優(yōu)化：盡量在字段后面使用模糊查詢(xún)應(yīng)盡量避免在 where 子句中使用 or 來(lái)連接條件，否則將導(dǎo)致引擎放棄使用索引而進(jìn)行全表掃描，優(yōu)化：可以用in代替or。盡量不要在 where 子句中對(duì)字段進(jìn)行表達(dá)式操作，這樣也會(huì)造成全表掃描。where條件里盡量不要進(jìn)行null值的判斷，null的判斷也會(huì)造成全表掃描。給字段添加默認(rèn)值，對(duì)默認(rèn)值進(jìn)行判斷。應(yīng)盡量避免在 where 子句中使用!=或<>操作符，否則將引擎放棄使用索引而進(jìn)行全表掃描應(yīng)盡量避免在where子句中對(duì)字段進(jìn)行函數(shù)操作，這將導(dǎo)致引擎放棄使用索引而進(jìn)行全表掃描。將表達(dá)式.函數(shù)操作移動(dòng)到等號(hào)右側(cè)。不要在 where 子句中的“=”左邊進(jìn)行函數(shù)、算術(shù)運(yùn)算或其他表達(dá)式運(yùn)算，否則系統(tǒng)將可能無(wú)法正確使用索引。盡量不要使用where 1=1的條件,有時(shí)候，在開(kāi)發(fā)過(guò)程中，為了方便拼裝查詢(xún)條件，我們會(huì)加上該條件，這樣，會(huì)造成進(jìn)行全表掃描。優(yōu)化：如果用代碼拼裝sql，則由代碼進(jìn)行判斷，沒(méi)where加where，有where加and如果用mybatis，請(qǐng)用mybatis的where語(yǔ)法。其他的優(yōu)化20.Update 語(yǔ)句，如果只更改1、2個(gè)字段，不要Update全部字段，否則頻繁調(diào)用會(huì)引起明顯的性能消耗，同時(shí)帶來(lái)大量日志。21.盡量使用Join 語(yǔ)句來(lái)替代子查詢(xún)，因?yàn)樽硬樵?xún)是嵌套查詢(xún)，而嵌套查詢(xún)會(huì)新創(chuàng)建一張臨時(shí)表，而臨時(shí)表的創(chuàng)建與銷(xiāo)毀會(huì)占用一定的系統(tǒng)資源以及花費(fèi)一定的時(shí)間，同時(shí)對(duì)于返回結(jié)果集比較大的子查詢(xún)，其對(duì)查詢(xún)性能的影響更大。22.對(duì)于多張大數(shù)據(jù)量（這里幾百條就算大了）的表JOIN，要先分頁(yè)再JOIN，否則邏輯讀會(huì)很高，性能很差。23.前提也是在sql基礎(chǔ)優(yōu)化完成后，有多表聯(lián)合查詢(xún)導(dǎo)致查詢(xún)數(shù)據(jù)很慢，可以在代碼上進(jìn)行分割，如一條語(yǔ)句查多個(gè)表，可以拆分成兩條sql語(yǔ)句或者多條sql語(yǔ)句，然后再代碼上進(jìn)行數(shù)據(jù)拼裝。24.業(yè)務(wù)層面優(yōu)化是指在sql基礎(chǔ)優(yōu)化上沒(méi)有問(wèn)題之后，然后一次性查詢(xún)的數(shù)據(jù)量很大，達(dá)到上億的數(shù)據(jù)量，即使是分頁(yè)也會(huì)很慢，所以要在業(yè)務(wù)層面進(jìn)行優(yōu)化，固定條件，緩存count值，避免每次查詢(xún)?nèi)頀呙栌?jì)算count值，每次更新都要對(duì)count值進(jìn)行同步修改Count優(yōu)化count(column) ：是表示結(jié)果集中有多少個(gè)column字段不為空的記錄。count(*) ：是表示整個(gè)結(jié)果集有多少條記錄count(1)：InnoDB 引擎遍歷整張表，但不取值。server 層對(duì)于返回的每一行，放一個(gè)數(shù)字“1”進(jìn)去，判斷是不可能為空的，按行累加。count(1) 執(zhí)行得要比 count(主鍵 id) 快。因?yàn)閺囊娣祷?id 會(huì)涉及到解析數(shù)據(jù)行，以及拷貝字段值的操作。原文鏈接：https://blog.csdn.net/m0_45312259/article/details/130841454

Redis數(shù)據(jù)一致性

1、一致性一致性是指系統(tǒng)中各節(jié)點(diǎn)數(shù)據(jù)保持一致。分布式系統(tǒng)中，可以理解為多個(gè)節(jié)點(diǎn)中的數(shù)據(jù)是一致的。一致性根據(jù)嚴(yán)苛程度分類(lèi)：強(qiáng)一致性：寫(xiě)進(jìn)去的數(shù)據(jù)是什么，讀出來(lái)的數(shù)據(jù)就是什么，對(duì)性能影響最大；弱一致性：數(shù)據(jù)寫(xiě)入成功后，系統(tǒng)不保證能立刻讀出最新的數(shù)據(jù)，也不承諾多久之后數(shù)據(jù)可以達(dá)到一致，但保證到某個(gè)時(shí)間級(jí)別后，數(shù)據(jù)能達(dá)到一致；最終一致性：最終一致性是弱一致性的一個(gè)特例，最終一致性同樣只保證數(shù)據(jù)寫(xiě)入成功后，在某個(gè)時(shí)間點(diǎn)后數(shù)據(jù)會(huì)達(dá)到一致。這個(gè)系統(tǒng)無(wú)法保證強(qiáng)一致性的時(shí)間片段被稱(chēng)為不一致窗口。不一致時(shí)間窗口的時(shí)間長(zhǎng)短取決于很多因素，比如副本個(gè)數(shù)、網(wǎng)絡(luò)延遲、系統(tǒng)負(fù)載等。最終一致性是弱一致性中非常受大眾推崇的一種一致性模型，也是目前業(yè)界在大型分布式系統(tǒng)的數(shù)據(jù)一致性上比較推崇的模型。2、緩存使用場(chǎng)景對(duì)于大部分系統(tǒng)而言，高并發(fā)常見(jiàn)于讀數(shù)據(jù)的場(chǎng)景，對(duì)于此場(chǎng)景我們可以使用緩存提升數(shù)據(jù)查詢(xún)速度。當(dāng)我們使用Redis作緩存的時(shí)候，常見(jiàn)場(chǎng)景如下所示：緩存存在如果數(shù)據(jù)在緩存中存在，則直接從緩存返回?cái)?shù)據(jù)至應(yīng)用，無(wú)需查詢(xún)數(shù)據(jù)庫(kù) 緩存不存在如果數(shù)據(jù)在緩存中不存在，則需查詢(xún)數(shù)據(jù)庫(kù)獲取數(shù)據(jù)并更新緩存。 對(duì)于大部分系統(tǒng)而言最終數(shù)據(jù)都會(huì)存儲(chǔ)在數(shù)據(jù)庫(kù)中，也就是系統(tǒng)需已數(shù)據(jù)庫(kù)中數(shù)據(jù)為準(zhǔn)，那么對(duì)于上圖緩存存在的場(chǎng)景下，當(dāng)數(shù)據(jù)庫(kù)中的數(shù)據(jù)發(fā)生變化時(shí)，就可能會(huì)出現(xiàn)數(shù)據(jù)不一致的問(wèn)題。實(shí)際情況下考慮網(wǎng)絡(luò)、操作、異常等種種因素，根本無(wú)法保證可以同時(shí)更新所有副本數(shù)據(jù)使得數(shù)據(jù)保持一致。因此，如何在最大程度上保證各副本數(shù)據(jù)一致的同時(shí)也不影響系統(tǒng)性能，成了各系統(tǒng)需要均衡的問(wèn)題。3、數(shù)據(jù)同步策略為保證緩存數(shù)據(jù)與數(shù)據(jù)庫(kù)數(shù)據(jù)一致，主要考慮如下兩種策略實(shí)現(xiàn)：1、先刪除緩存，再更新數(shù)據(jù)庫(kù)；2、先更新數(shù)據(jù)庫(kù)，再刪除緩存；當(dāng)然除了這兩種策略之外，還有其他策略如將刪除緩存改為更新緩存，但考慮高頻繁更新及熱冷數(shù)據(jù)場(chǎng)景下緩存使用效率問(wèn)題，個(gè)人不推薦更新緩存方式，所以此處不做展開(kāi)。3.1 先刪除緩存，在更新數(shù)據(jù)庫(kù)操作流程如圖如上圖，若先刪除緩存，再更新數(shù)據(jù)庫(kù)，則可能存在如下問(wèn)題：若步驟5、6、7順序發(fā)生在步驟3、4之前或步驟3更新失敗，則步驟8中線(xiàn)程B查詢(xún)出的數(shù)據(jù)為舊數(shù)據(jù)，導(dǎo)致重新寫(xiě)入緩存的也為舊數(shù)據(jù)。3.1.1 解決思路失敗重試 + 延時(shí)雙刪如圖中紅色部分所述，線(xiàn)程A在步驟4數(shù)據(jù)更新成功后，延遲一段時(shí)間，再次刪除緩存，這樣即可解決并發(fā)場(chǎng)景下線(xiàn)程B并發(fā)操作導(dǎo)致緩存與數(shù)據(jù)庫(kù)數(shù)據(jù)不一致問(wèn)題。延遲時(shí)間視實(shí)際業(yè)務(wù)場(chǎng)景對(duì)時(shí)間敏感度而定。 3.2 先更新數(shù)據(jù)庫(kù)，再刪除緩存操作流程如圖如上圖，若先更新數(shù)據(jù)庫(kù)，再刪除緩存，則可能存在如下問(wèn)題：步驟5、6發(fā)生在步驟3之前或步驟3刪除緩存失敗，則線(xiàn)程B通過(guò)步驟5會(huì)拿到緩存數(shù)據(jù)，但此時(shí)獲取到的緩存數(shù)據(jù)仍為舊數(shù)據(jù)。3.2.1 解決思路訂閱binlog數(shù)據(jù)庫(kù)的每一步操作均會(huì)寫(xiě)入binlog日志，可以通過(guò)監(jiān)聽(tīng)binlog，實(shí)時(shí)感知數(shù)據(jù)變化情況，根據(jù)數(shù)據(jù)變化情況刪除redis并添加重試機(jī)制，直至redis刪除成功。引入消息隊(duì)列上圖步驟3中若Redis刪除失敗，則將Redis key放入消息隊(duì)列，消費(fèi)端監(jiān)聽(tīng)消息隊(duì)列并刪除Redis直至刪除成功；4 總結(jié)需要注意的是3.1.1 和 3.2.1中描述的解決方案也只能保證最終數(shù)據(jù)一致性，無(wú)法保證強(qiáng)一致性，如上述各場(chǎng)景中若線(xiàn)程A操作異常，在通過(guò)3.1.1 和 3.2.1的方式解決問(wèn)題之前，其他線(xiàn)程仍有可能獲取到臟數(shù)據(jù)。原文鏈接：https://blog.csdn.net/sxg0205/article/details/127531279

UI的設(shè)計(jì)中顏色的知識(shí)

一、RGB888的顯示即紅色，綠色，藍(lán)色都為8位，即通常說(shuō)的24位色?？梢院芎蔑@示各種過(guò)渡顏色。從硬件上，R、G、B三基色的連接線(xiàn)各需要有8根，即24根數(shù)據(jù)線(xiàn)；軟件上存儲(chǔ)的數(shù)據(jù)量也需要24位，即3個(gè)字節(jié)，如果有透明度的顯示效果則需要在加上1個(gè)字節(jié)的透明度數(shù)據(jù)值。紅色8位，按二進(jìn)制表達(dá)為1111-1111， 即從0~255完全可以表現(xiàn)出來(lái)。綠色8位，按二進(jìn)制表達(dá)為1111-1111， 即從0~255完全可以表現(xiàn)出來(lái)。藍(lán)色8位，按二進(jìn)制表達(dá)為1111-1111， 即從0~255完全可以表現(xiàn)出來(lái)。二、RGB565的顯示：即紅色只有高5位，綠色只有高6位，藍(lán)色只有高5位。即通常說(shuō)的16位色。在顯示低位顏色的過(guò)渡效果時(shí)，表現(xiàn)不出來(lái)。從硬件上，R、G、B三基色的連接線(xiàn)各需要5、6、5根，即16跟數(shù)據(jù)線(xiàn)；軟件上存儲(chǔ)的數(shù)據(jù)量需要16位，即2個(gè)字節(jié)，如果有透明度的顯示效果則需要在加上1個(gè)字節(jié)的透明度數(shù)據(jù)值。紅色只有高5位，按二進(jìn)制表達(dá)為1111-1000，低三位永遠(yuǎn)為0值。即顏色值為0，8，16，24，32，…… 248，即間隔值為8。比如紅色值為1~7，顯示表現(xiàn)出來(lái)的值只能為0；又如紅色值256，顯示變現(xiàn)出來(lái)的值只能為248。綠色只有高6位，按二進(jìn)制表達(dá)為1111-1100，低兩位永遠(yuǎn)為0值。即顏色值為0，4，8，12，16，20，…… 252，即間隔值為4。比如綠色值為1~3，顯示表現(xiàn)出來(lái)的值只能為0； 又如綠色值256，顯示變現(xiàn)出來(lái)的值只能為252藍(lán)色只有高5位，按二進(jìn)制表達(dá)為1111-1000，低三位永遠(yuǎn)為0值。即顏色值為0，8，16，24，32，248，即間隔值為8。比如藍(lán)色值為1~7，顯示表現(xiàn)出來(lái)的值只能為0；又如藍(lán)色值256，顯示變現(xiàn)出來(lái)的值只能為248。，選取了坐標(biāo)值（X—372，Y—134）到（X—397，Y—134）進(jìn)行查看過(guò)渡顏色的變化值，如下：X372  Y134 --  R30 G159 B231   X373  Y134 --  R30 G158 B231   Y134 --  R30 G158 B230X375  Y134 --  R30 G156 B230X376  Y134 --  R30 G157 B230X377  Y134 --  R30 G156B230X378  Y134 --  R30 G155 B230X379  Y134 --  R30 G154 B229X380  Y134 --  R30 G153 B229X381  Y134 --  R30 G153 B228X382  Y134 --  R30 G152 B228X383  Y134 --  R29 G151 B228X384  Y134 --  R29 G150 B228X385  Y134 --  R29 G150 B227X386  Y134 --  R29 G149 B227X387  Y134 --  R29 G148 B227X388  Y134 --  R29 G148 B227X389  Y134 --  R29 G147 B226X390  Y134 --  R29 G146 Y134 --  R29 G146 B226Y134 --  R29 G145 B226X393  Y134 --  R29 G144 B225Y134 --  R29 G143 B225X395  Y134 --  R29 G143 B225X396  Y134 --  R30 G142 B224 X397  Y134 --  R142 G198 B239過(guò)渡色為水平變化，變化值基本是在4以?xún)?nèi)，如前面所述這些點(diǎn)之間的過(guò)渡變化RGB565的驅(qū)動(dòng)顯示中體現(xiàn)不出來(lái)。所以，UI設(shè)計(jì)中，避免過(guò)渡色為低位的顏色值變化。三、切圖的原則：3.1、分切圖的規(guī)則為選取動(dòng)態(tài)部分、可點(diǎn)擊部分；3.2、避免整套UI的切圖都采用PNG格式應(yīng)用，因?yàn)镻NG圖在轉(zhuǎn)換成位圖加透明度的數(shù)據(jù)格式時(shí)，占用的存儲(chǔ)量比較大，可能造成位置SPI存儲(chǔ)器容量不足的情況。有透明度顯示效果的UI，可以分切成PNG格式。一般建議主頁(yè)面的圖標(biāo)或部分頁(yè)面的圖標(biāo)的設(shè)計(jì)采用透明圖層的設(shè)計(jì)效果。大部分的UI設(shè)計(jì)建議采用不透明，分切圖的輸出采用JPEG格式?？梢源蟠蟮販p少UI素材的數(shù)據(jù)存儲(chǔ)量。

HTTPS工作原理

HTTPS是什么HTTPS全稱(chēng)為Hypertext Transfer Protocol over Secure Socket Layer，及以安全為目標(biāo)的HTTP通道，簡(jiǎn)單說(shuō)就是HTTP的安全版本。HTTPS其實(shí)是由兩部分組成的：HTTP+TLS/SSL，即HTTP下加入TLS/SSL層，HTTPS的安全基礎(chǔ)就是TLS/SSL。服務(wù)端和客戶(hù)端的信息傳輸都會(huì)通過(guò)TLS/SSL進(jìn)行加密，所以傳輸?shù)臄?shù)據(jù)都是加密之后的數(shù)據(jù)。TLS的前身就是SSL協(xié)議，因此沒(méi)有特別說(shuō)明TLS/SSL說(shuō)的都是同一個(gè)東西。HTTP在安全方面的缺陷HTTP本身是明文傳輸?shù)?，沒(méi)有經(jīng)過(guò)任何安全處理。例如用戶(hù)在百度搜索了一個(gè)關(guān)鍵字，比如"蘋(píng)果手機(jī)"，中間者完全能夠查到到這個(gè)信息，并且有可能打電話(huà)過(guò)來(lái)騷擾用戶(hù)。也有一些用戶(hù)投訴使用百度時(shí)，發(fā)現(xiàn)首頁(yè)或者結(jié)果頁(yè)浮了一個(gè)很長(zhǎng)很大的廣告，這也肯定是中間者往頁(yè)面插的廣告內(nèi)容。如果劫持技術(shù)比較低劣的話(huà)，用戶(hù)甚至無(wú)法訪(fǎng)問(wèn)百度。這里提到的一些中間者主要指一些網(wǎng)絡(luò)節(jié)點(diǎn)，使用戶(hù)數(shù)據(jù)在瀏覽器和百度服務(wù)器之間傳輸必須要經(jīng)過(guò)的節(jié)點(diǎn)，比如WIFI熱點(diǎn)、路由器、防火墻、反向代理、緩存服務(wù)器等。在HTTP協(xié)議下，中間者可以隨意嗅探用戶(hù)搜索內(nèi)容，竊取隱私甚至篡改網(wǎng)頁(yè)。不過(guò)HTTPS是這些劫持行為的克星，能夠完全有效地防御?？傮w來(lái)說(shuō)，HTTPS協(xié)議提供了三個(gè)強(qiáng)大的功能來(lái)對(duì)抗上述的劫持行為：1、內(nèi)容加密。瀏覽器到百度服務(wù)器的內(nèi)容都是以加密形式傳輸?shù)?，中間者無(wú)法直接查看原始內(nèi)容2、身份認(rèn)證。保證用戶(hù)訪(fǎng)問(wèn)的是百度服務(wù)，即使被DNS劫持到了第三方站點(diǎn)，也會(huì)提醒用戶(hù)沒(méi)有訪(fǎng)問(wèn)百度服務(wù)3、數(shù)據(jù)完整。防止內(nèi)容被第三方冒充或篡改。

運(yùn)營(yíng)職責(zé)及工作內(nèi)容梳理

運(yùn)營(yíng)主要職責(zé)梳理運(yùn)營(yíng)是一個(gè)多維度、跨領(lǐng)域的職責(zé)，涉及到企業(yè)多個(gè)層面的管理和執(zhí)行。以下是運(yùn)營(yíng)的主要職責(zé)及其包含的關(guān)鍵內(nèi)容:一、制定運(yùn)營(yíng)策略1.根據(jù)企業(yè)整體戰(zhàn)略和市場(chǎng)環(huán)境，制定運(yùn)營(yíng)計(jì)劃與目標(biāo)。2.分析行業(yè)趨勢(shì)、競(jìng)爭(zhēng)對(duì)手，以及用戶(hù)需求和行為，調(diào)整運(yùn)營(yíng)策略。3.設(shè)定關(guān)鍵績(jī)效指標(biāo)(KPI)，并監(jiān)控運(yùn)營(yíng)效果，持續(xù)優(yōu)化運(yùn)營(yíng)策略。二、用戶(hù)增長(zhǎng)與維護(hù)1.通過(guò)各種渠道吸引新用戶(hù)，提高用戶(hù)數(shù)量和活躍度。2.建立用戶(hù)畫(huà)像，精準(zhǔn)推送個(gè)性化內(nèi)容，提升用戶(hù)體驗(yàn)。3.定期與用戶(hù)互動(dòng)，收集用戶(hù)反饋，維護(hù)用戶(hù)關(guān)系，提高用戶(hù)忠誠(chéng)度。三、內(nèi)容管理與策劃1.負(fù)責(zé)平臺(tái)內(nèi)容的規(guī)劃、更新和維護(hù)，確保內(nèi)容質(zhì)量和時(shí)效性。2.策劃并推出有吸引力的內(nèi)容，提高用戶(hù)粘性和轉(zhuǎn)化率。3.與內(nèi)容創(chuàng)作者合作，優(yōu)化內(nèi)容創(chuàng)作流程，提高內(nèi)容產(chǎn)出效率。四、數(shù)據(jù)分析與優(yōu)化1.收集、整理和分析運(yùn)營(yíng)數(shù)據(jù)，為決策提供支持。2.通過(guò)數(shù)據(jù)分析發(fā)現(xiàn)潛在問(wèn)題，提出優(yōu)化建議。3.跟蹤數(shù)據(jù)指標(biāo)變化，評(píng)估運(yùn)營(yíng)效果，及時(shí)調(diào)整策略。五、活動(dòng)策劃與執(zhí)行1.策劃線(xiàn)上線(xiàn)下活動(dòng)，提升品牌知名度和用戶(hù)參與度。2.協(xié)調(diào)各方資源，確?；顒?dòng)順利進(jìn)行。3.對(duì)活動(dòng)效果進(jìn)行評(píng)估和總結(jié)，為后續(xù)活動(dòng)提供經(jīng)驗(yàn)。六、合作伙伴關(guān)系維護(hù)1.拓展并維護(hù)合作伙伴關(guān)系，為企業(yè)爭(zhēng)取更多資源和支持。2.與合作伙伴共同開(kāi)展活動(dòng)或項(xiàng)目，實(shí)現(xiàn)互利共贏(yíng)。3.關(guān)注合作伙伴動(dòng)態(tài)，及時(shí)調(diào)整合作策略。七、監(jiān)測(cè)市場(chǎng)動(dòng)態(tài)1.關(guān)注行業(yè)動(dòng)態(tài)、政策法規(guī)變化，及時(shí)調(diào)整運(yùn)營(yíng)策略。2.收集競(jìng)爭(zhēng)對(duì)手信息，分析其運(yùn)營(yíng)策略和優(yōu)勢(shì)劣勢(shì)。3.預(yù)測(cè)市場(chǎng)趨勢(shì)，為企業(yè)決策提供參考依據(jù)。八、團(tuán)隊(duì)協(xié)調(diào)與管理1.組建并管理運(yùn)營(yíng)團(tuán)隊(duì)，明確各成員職責(zé)和分工。2.定期組織團(tuán)隊(duì)培訓(xùn)和分享會(huì)，提升團(tuán)隊(duì)能力。3.協(xié)調(diào)團(tuán)隊(duì)內(nèi)部溝通與合作，確保各項(xiàng)任務(wù)順利完成。3.預(yù)測(cè)市場(chǎng)趨勢(shì)，為企業(yè)決策提供參考依據(jù)。八、團(tuán)隊(duì)協(xié)調(diào)與管理1.組建并管理運(yùn)營(yíng)團(tuán)隊(duì)，明確各成員職責(zé)和分工。2.定期組織團(tuán)隊(duì)培訓(xùn)和分享會(huì)，提升團(tuán)隊(duì)能力。3.協(xié)調(diào)團(tuán)隊(duì)內(nèi)部溝通與合作，確保各項(xiàng)任務(wù)順利完成。綜上所述，運(yùn)營(yíng)的主要職責(zé)涵蓋了企業(yè)運(yùn)營(yíng)的各個(gè)方面，需要運(yùn)營(yíng)人員具備全面的知識(shí)和技能，同時(shí)還需要具備敏銳的市場(chǎng)洞察力和卓越的團(tuán)隊(duì)協(xié)調(diào)能力。通過(guò)不斷優(yōu)化和創(chuàng)新，運(yùn)營(yíng)工作可以為企業(yè)創(chuàng)造更大的價(jià)值。

開(kāi)發(fā)時(shí)常用的推薦算法

推薦系統(tǒng)在幫助用戶(hù)發(fā)現(xiàn)可能感興趣的產(chǎn)品、服務(wù)或信息方面發(fā)揮著重要作用。下面是一些常用的推薦算法：1. 協(xié)同過(guò)濾用戶(hù)基于協(xié)同過(guò)濾（User-Based Collaborative Filtering）基于用戶(hù)之間的相似性為用戶(hù)推薦物品。算法會(huì)找出與目標(biāo)用戶(hù)興趣相似的其他用戶(hù)，然后推薦那些用戶(hù)喜歡的物品。物品基于協(xié)同過(guò)濾（Item-Based Collaborative Filtering）基于物品之間的相似性為用戶(hù)推薦物品。算法會(huì)為用戶(hù)推薦與他們之前喜歡的物品相似的物品。2. 基于內(nèi)容的推薦（Content-Based Filtering）根據(jù)用戶(hù)之前喜歡的內(nèi)容的特征和屬性，推薦具有相似特征的新內(nèi)容。這種方法依賴(lài)于物品的元數(shù)據(jù)，如電影的導(dǎo)演、演員列表或文章的關(guān)鍵詞。3. 矩陣分解（Matrix Factorization）如奇異值分解（SVD）和交替最小二乘法（ALS），通過(guò)分解用戶(hù)-物品交互矩陣，找到潛在的因子來(lái)預(yù)測(cè)用戶(hù)對(duì)未評(píng)分物品的偏好。4. 深度學(xué)習(xí)方法利用神經(jīng)網(wǎng)絡(luò)進(jìn)行特征學(xué)習(xí)和推薦，如使用自編碼器、卷積神經(jīng)網(wǎng)絡(luò)（CNNs）、循環(huán)神經(jīng)網(wǎng)絡(luò)（RNNs）和最近的注意力機(jī)制和Transformer模型。深度學(xué)習(xí)方法可以從復(fù)雜的數(shù)據(jù)中學(xué)習(xí)到深層的特征表示，提高推薦的準(zhǔn)確性和個(gè)性化水平。5. 混合推薦系統(tǒng)（Hybrid Recommender Systems）結(jié)合了以上一個(gè)或多個(gè)推薦技術(shù)的方法，比如將內(nèi)容推薦和協(xié)同過(guò)濾結(jié)合起來(lái)，以利用各自的優(yōu)勢(shì)并克服單一方法的限制?；旌戏椒梢蕴岣咄扑]系統(tǒng)的準(zhǔn)確性和覆蓋面。這些算法可以根據(jù)具體的應(yīng)用場(chǎng)景和需求單獨(dú)使用，也可以結(jié)合使用來(lái)構(gòu)建更復(fù)雜的推薦系統(tǒng)。選擇合適的推薦算法取決于可用的數(shù)據(jù)類(lèi)型、系統(tǒng)的目標(biāo)以及用戶(hù)的期望等因素。