沒在mysql中試過，不過最近在使用集算器，可以給樓主做下參考。
創(chuàng)新互聯(lián)是專業(yè)的息烽網站建設公司，息烽接單;提供網站設計、成都做網站,網頁設計,網站設計,建網站,PHP網站建設等專業(yè)做網站服務;采用PHP框架,可快速的進行息烽網站開發(fā)網頁制作和功能擴展;專業(yè)做搜索引擎喜愛的網站,專業(yè)的做網站團隊,希望更多企業(yè)前來合作!
首先，不是所有的數(shù)據(jù)庫都提供 pivot；其次，就算所有的數(shù)據(jù)庫都提供 pivot，但如果是匯總了多個數(shù)據(jù)庫的數(shù)據(jù)后還想再來個 pivot？那還是要用到集算器的 pivot。
下面我們來看集算器的 pivot 如何使用
代碼說明：
A1：第一步連接數(shù)據(jù)庫
A2：第二步提取數(shù)據(jù)做預處理 (這一步可進一步擴展為做匯總或聚合等復雜的計算，具體方法請參考相關文章)
A3：第三步即實現(xiàn) pivot 的列轉行功能并呈現(xiàn)出來
查詢優(yōu)化器負責將SQL查詢轉換為盡可能高效的執(zhí)行計劃，但隨著數(shù)據(jù)環(huán)境不斷變化，查詢優(yōu)化器可能無法找到最佳的執(zhí)行計劃，導致SQL效率低下。造成這種情況的原因是優(yōu)化器對查詢的數(shù)據(jù)了解的不夠充足，例如：每個表有多少行數(shù)據(jù)，每列中有多少不同的值，每列的數(shù)據(jù)分布情況。
因此MySQL8.0.3推出了直方圖(histogram)功能，直方圖是列的數(shù)據(jù)分布的近似值，其向優(yōu)化器提供更多的統(tǒng)計信息。比如字段的個數(shù)，每個不同值的百分比，最大/最小值等。MySQL的直方圖分為：等寬直方圖和等高直方圖，MySQL會自動分配使用哪種類型的直方圖，無法干預
直方圖同時也存在一定的限制條件：
創(chuàng)建和刪除直方圖
創(chuàng)建語法
創(chuàng)建直方圖時能夠同時為多個列創(chuàng)建直方圖，但必須指定bucket數(shù)量，范圍在1-1024之間，默認100。對于bucket數(shù)量應該綜合考慮其有多少不同值、數(shù)據(jù)的傾斜度、精度等，建議從較低的值開始，不符合再依次增加。
刪除語法
直方圖信息
MySQL通過字典表column_statistics來保存直方圖的定義，每行記錄對應一個字段的直方圖，已JSON格式保存。
MySQL為employees的first_name字段分配了等高直方圖，默認為100個bucket。
當生成直方圖時，MySQL會將所有數(shù)據(jù)都加載到內存中，并在內存中執(zhí)行所有工作。如果在大表上生成直方圖，可能會將幾百M的數(shù)據(jù)讀取到內存中的風險，因此我們可以通過參數(shù) hitogram_generation_max_mem_size 來控制生成直方圖最大允許的內存量，當指定內存滿足不了所有數(shù)據(jù)集時就會采用采樣的方式。
從MySQL8.0.19開始，存儲引擎自身提供了存儲在表中數(shù)據(jù)的采樣實現(xiàn)，存儲引擎不支持時，MySQL使用默認采樣需要全表掃描，這樣對于大表來說成本太高，采樣實現(xiàn)避免了全表掃描提高采樣性能。
通過INNODB_METRICS計數(shù)器可以監(jiān)視數(shù)據(jù)頁的采樣情況，這需要提前開啟計數(shù)器
采樣率的計算公式為： sampled_page_read/(sampled_pages_read + sampled_pages_skipped)
優(yōu)化案例
復制一張表出來，源表不添加直方圖，新表添加直方圖
分別在兩張表上查看SQL的執(zhí)行計劃
可以看出Cost值從30214.45降到了18744.56，掃描行數(shù)從299822降到了41654，性能有所提升
mysql 開啟查詢緩存可以有兩種方法來開啟一種是使用set命令來進行開啟，另一種是直接修改my.ini文件來直接設置都是非常的簡單的哦。
開啟緩存，設置緩存大小，具體實施如下：
windows下是my.ini，linux下是my.cnf;
在配置文件的最后追加上：
需要重啟mysql生效；
b) 開啟緩存,兩種方式：
a)使用mysql命令：
如果報錯：
Query cache is disabled; restart the server with query_cache_type=1 to enable it，還是老老實實的該配置文件，然后重啟吧，原因如下：
查看是否設置成功
show variables like "%query_cache%" 查看是否設置成功：
當然如果你的數(shù)據(jù)表有更新怎么辦，沒關系mysql默認會和這個表有關系的緩存刪掉，下次查詢的時候會直接讀表然后再緩存
下面是一個簡單的例子：
以上的相關內容就是對mysql緩存查詢和設置的介紹，望你能有所收獲。
一般，我們會把 query_cache_type 設置為 ON,默認情況下應該是ON
query_cache_type有3個值 0代表關閉查詢緩存OFF，1代表開啟ON，2（DEMAND）代表當sql語句中有SQL_CACHE關鍵詞時才緩存，如：
這樣 當我們執(zhí)行 select id,name from tableName; 這樣就會用到查詢緩存。
①在 query_cache_type 打開的情況下，如果你不想使用緩存，需要指明
select sql_no_cache id,name from tableName;
②當sql中用到mysql函數(shù)，也不會緩存
當然也可以禁用查詢緩存： mysql set session query_cache_type=off;
上面的顯示，表示設置查詢緩存是可用的。
表示查詢緩存大小，也就是分配內存大小給查詢緩存，如果你分配大小為0，
那么 第一步 和 第二步 起不到作用，還是沒有任何效果。
上面是 mysql6.0設置默認的，之前的版本好像默認是0的，那么就要自己設置下。
設置
這里是設置1M左右，900多K。
再次查看下:
顯示我們設置新的大小，表示設置成功。
例如： 如果查詢結果很大， 也緩存？？？？這個明顯是不可能的。
MySql 可以設置一個最大的緩存值，當你查詢緩存數(shù)結果數(shù)據(jù)超過這個值就不會
進行緩存。缺省為1M，也就是超過了1M查詢結果就不會緩存。
這個是默認的數(shù)值，如果需要修改，就像設置緩存大小一樣設置，使用set
重新指定大小。
好了，通過4個步驟就可以 打開了查詢緩存，具體值的大小和查詢的方式 這個因不同
的情況來指定了。
mysql查詢緩存相關變量
MySQL 提供了一系列的 Global Status 來記錄 Query Cache 的當前狀態(tài)，具體如下：
Qcache_free_blocks：目前還處于空閑狀態(tài)的 Query Cache 中內存 Block 數(shù)目
Qcache_free_memory：目前還處于空閑狀態(tài)的 Query Cache 內存總量
Qcache_hits：Query Cache 命中次數(shù)
Qcache_inserts：向 Query Cache 中插入新的 Query Cache 的次數(shù)，也就是沒有命中的次數(shù)
Qcache_lowmem_prunes：當 Query Cache 內存容量不夠，需要從中刪除老的 Query Cache 以給新的 Cache 對象使用的次數(shù)
Qcache_not_cached：沒有被 Cache 的 SQL 數(shù)，包括無法被 Cache 的 SQL 以及由于 query_cache_type 設置的不會被 Cache 的 SQL
Qcache_queries_in_cache：目前在 Query Cache 中的 SQL 數(shù)量
Qcache_total_blocks：Query Cache 中總的 Block 數(shù)量
檢查是否從查詢緩存中受益的最簡單的辦法就是檢查緩存命中率
當服務器收到SELECT 語句的時候，Qcache_hits 和Com_select 這兩個變量會根據(jù)查詢緩存
的情況進行遞增
查詢緩存命中率的計算公式是：Qcache_hits/(Qcache_hits + Com_select)。
query_cache_min_res_unit的配置是一柄”雙刃劍”，默認是4KB，設置值大對大數(shù)據(jù)查詢有好處，但如果你的查詢都是小數(shù)據(jù) 查詢，就容易造成內存碎片和浪費。
查詢緩存碎片率 = Qcache_free_blocks / Qcache_total_blocks * 100%
如果查詢緩存碎片率超過20%，可以用FLUSH QUERY CACHE整理緩存碎片，或者試試減小query_cache_min_res_unit，如果你的查詢都是小數(shù)據(jù)量的話。
查詢緩存利用率 = (query_cache_size - Qcache_free_memory) / query_cache_size * 100%
查詢緩存利用率在25%以下的話說明query_cache_size設置的過大，可適當減小;查詢緩存利用率在80%以上而且 Qcache_lowmem_prunes 50的話說明query_cache_size可能有點小，要不就是碎片太多。
查詢緩存命中率 = (Qcache_hits - Qcache_inserts) / Qcache_hits * 100%
示例服務器 查詢緩存碎片率 = 20.46%，查詢緩存利用率 = 62.26%，查詢緩存命中率 = 1.94%，命中率很差，可能寫操作比較頻繁吧，而且可能有些碎片。
查詢緩存可以看做是SQL文本和查詢結果的映射。如果第二次查詢的SQL和第一次查詢的SQL完全相同（注意必須是完全相同，即使多一個空格或者大小寫不同都認為不同）且開啟了查詢緩存，那么第二次查詢就直接從查詢緩存中取結果，可以通過下面的SQL來查看緩存命中次數(shù)（是個累加值）：
另外即使完全相同的SQL，如果使用不同的字符集、不同的協(xié)議等也會被認為是不同的查詢而分別進行緩存。
在表的結構或數(shù)據(jù)發(fā)生改變時，查詢緩存中的數(shù)據(jù)不再有效。有這些INSERT、UPDATE、 DELETE、TRUNCATE、ALTER TABLE、DROP TABLE或DROP DATABASE會導致緩存數(shù)據(jù)失效。所以查詢緩存適合有大量相同查詢的應用，不適合有大量數(shù)據(jù)更新的應用。
可以使用下面三個SQL來清理查詢緩存：
1、FLUSH QUERY CACHE; // 清理查詢緩存內存碎片。
2、RESET QUERY CACHE; // 從查詢緩存中移出所有查詢。
3、FLUSH TABLES; //關閉所有打開的表，同時該操作將會清空查詢緩存中的內容。
Query Cache是MySQL Server層的一個非常好的特性，對于小數(shù)據(jù)集或訪問量非常集中的應用場景，有非常好的性能提升，但是Query Cache引入了一些新的問題，而且大部分場景下比較雞肋，官方打算棄用了
參考：
mysql里面利潤率算法如下。
1、selectnameas商品名稱。
2、as商品單件利潤fromtb1commodity。
重慶分公司
重慶分公司
