MySQL

前言     分區是指根據一定的規則將一個大表分解成多個更小的部分，這裡的規則一般就是利用分區規則將表進行水平切分；邏輯上沒有發生變化但實際上表已經被拆分成了多個物理對象，每個分成被劃分成了一個獨立的對象。相對於沒有分區的當個表而言分區的表有很多的優勢包括： 並發統計查詢、快速歸檔刪除分區資料、分散儲存、查詢效能更佳。mysql5.7以後查詢語句支援指定分區例如：“ SELECT * FROM t PARTITION (p0,p1) WHERE c

問題：使用某大腿寫的遠程工具管理Mysql資料庫時發現所有資料能正常顯示，但是無法進行刪除、修改等操作。　　思路：可以遠程讀取到資料庫裡的資訊，說明當前主機可以遠端連線資料庫。卻無法進行刪除、修改這些操作，說明某些許可權並未賦予當前遠端使用者。　　解決方案：　　查看目前使用者許可權show grants for username　　顯示目前使用者下的許可權為:select,insert,update,deleteGRANT USAGE ON *.* TO 'username'@'host'

一、安裝配置MySQL的yum源# 安裝MySQL的yum源，下面是RHEL6系列mysql5.6的下載地址：wget http://dev.mysql.com/get/mysql-community-release-el6-5.noarch.rpm下面是RHEL6系列mysql5.7的下載地址：wget http://repo.mysql.com//mysql57-community-release-el6-8.noarch.rpm安裝yum源。 rpm -ivh

索引的目的在於提高查詢效率，可以類比字典，如果要查“mysql”這個單詞，我們肯定需要定位到m字母，然後從下往下找到y字母，再找到剩下的sql。如果沒有索引，那麼你可能需要把所有單詞看一遍才能找到你想要的。1.索引的優點假設你擁有三個未索引的表t1、t2和t3，每個表都分別包含資料列i1、i2和i3，並且每個表都包含了1000條資料行，其序號從1到1000。尋找某些值匹配的資料行組合的查詢可能如下所示：SELECT t1.i1, t2.i2, t3.i3FROM t1, t2, t3WHERE

 MySQL會出現中文亂碼的原因在於1.server本身設定問題，一般來說是latin12.建庫建表時沒有制定編碼格式。MySql中表單輸入資料出現中文亂碼的解決方案：1.建庫的時候CREATE DATABASE test CHARACTER SET 'utf8' COLLATE 'utf8_general_ci'; 2.建表的時候CREATE TABLE content ( text VARCHAR(100)) ENGINE=InnoDB DEFAULT CHARSET=utf8;

前言在資料庫的開發過程中，經常會遇到複雜的商務邏輯和對資料庫的操作，這個時候就會用預存程序來封裝資料庫操作。如果項目的預存程序較多，書寫又沒有一定的規範，將會影響以後的系統維護困難和大預存程序邏輯的難以理解，另外如果資料庫的資料量大或者項目對預存程序的效能要求很，就會遇到最佳化的問題，否則速度有可能很慢，經過親身經驗，一個經過最佳化過的預存程序要比一個效能差的預存程序的效率甚至高几百倍。下面介紹某一個MySQL預存程序最佳化的整個過程。在本文中，需要被最佳化的預存程序如下：drop

1. 常見命令串連本機資料庫與遠端資料庫（172.16.xx.xx:3306）：mysql -h localhost -u root -p123 mysql -h 172.16.xx.xx -P 3306 -u root -p 2. DDL資料定義語言 (Data Definition Language)（Data Definition Lanuage,

前言JSON是一種輕量級的資料交換格式，採用了獨立於語言的文字格式設定，類似XML，但是比XML簡單，易讀並且易編寫。對機器來說易於解析和產生，並且會減少網路頻寬的傳輸。JSON的格式非常簡單：名稱/索引值。之前MySQL版本裡面要實現這樣的儲存，要麼用VARCHAR要麼用TEXT大文本。 MySQL5.7發布後，專門設計了JSON資料類型以及關於這種類型的檢索以及其他函數解析。下面一起來實際操作一下。建立帶有 JSON 欄位的表比如一個‘文章'表，欄位包括id、標題 title、標籤

我們知道倒序輸出是很簡單的select * from table order by id desc直接這樣就可以那麼現在的問題在於日期欄位怎麼來倒序輸出這裡我們用到cast()來將指定的欄位轉換為我們需要的類型如下是實際項目中的sql語句select * from water where phoneNumber=@phoneNumber order by cast(date as datetime)

本文執行個體總結了MySQL資料庫最佳化技術的索引用法。分享給大家供大家參考，具體如下：這裡緊接上一篇《MySQL資料庫最佳化技術之配置技巧總結》，進一步分析索引最佳化的技巧：(七)表的最佳化1. 選擇合適的資料引擎MyISAM:適用於大量的讀操作的表InnoDB:適用於大量的寫讀作的表2.選擇合適的列類型使用 SELECT * FROM TB_TEST PROCEDURE ANALYSE()可以對這個表的每一個欄位進行分析，給出最佳化列類型建議3.對於不儲存NULL值的列使用NOT NULL，

本文執行個體講述了MySQL資料庫最佳化技術的配置方法。分享給大家供大家參考，具體如下：(一)減少資料庫訪問對於可以靜態化的頁面，儘可能靜態化對一個動態網頁面中可以靜態局部，採用靜態化部分資料可以產生XML，或者文字檔形式儲存使用資料緩衝技術，例如： MemCached(二)最佳化的檢測方法1.使用者體驗檢測2.Mysql狀態檢測在Mysql命令列裡面使用show status命令，得到當前mysql狀態。主要關注下列屬性：key_read_requests

本文執行個體分析了MySQL索引用法。分享給大家供大家參考，具體如下：MYSQL描述：一個文章庫，裡面有兩個表：category和article。category裡面有10條分類資料。article裡面有20萬條。article裡面有一個"article_category"欄位是與category裡的"category_id"欄位相對應的。article表裡面已經把 article_category字義為了索引。資料庫大小為1.3G。問題描述：執行一個很普通的查詢：複製代碼

MySQL“自古以來”都有一個神秘的HANDLER命令，而此命令非SQL標準文法，可以降低最佳化器對於SQL語句的解析與最佳化開銷，從而提升查詢效能。看到這裡，可能有小夥伴不淡定了，這麼好的東西為啥沒廣泛使用呢？這不是與幾年前很夯的handlersocket外掛程式類似嗎？那麼，我們先來看看Handler文法說明：HANDLER tbl_name OPEN [ [AS] alias]HANDLER tbl_name READ index_name { = | <= | >= |

Inside君整理了一份最新基於MySQL 5.6和5.7的設定檔範本，基本上可以說覆蓋90%的調優選項，使用者只需根據自己的伺服器配置稍作修改即可，如InnoDB緩衝池的大小、IO能力（innodb_buffer_pool_size，innodb_io_capacity)。特別注意，這份設定檔不用修改，可以直接運行在MySQL

最近經常有收到MySQL執行個體類似記憶體不足的警示資訊，登陸到伺服器上一看發現MySQL 吃掉了99%的記憶體，God ！有時候沒有及時處理，核心就會自己幫我們重啟下MySQL，然後我們就可以看到 dmesg 資訊有如下記錄：Mar 9 11:29:16 xxxxxx kernel: mysqld invoked oom-killer: gfp_mask=0x201da, order=0, oom_adj=0, oom_score_adj=0Mar 9 11:29:16 xxxxxx

這裡就涉及到一個問題，到底Kill掉誰呢？一般稍微瞭解一些Linux核心的同學第一反應是誰用的最多，就Kill掉誰。這當然是Linux核心首先考慮的一種重要因素，但是也不完全是這樣的，我們查一些Linux的核心方面的資料，可以知道其實Kill誰是由/proc/<pid>/oom_score來決定的，這個值每個進程一個，是由Linux核心的oom_badness()函數負責計算的。那下面我們來仔細讀一讀badness()函數。  在badness()函數的注釋部分，

RDS（網易雲關聯式資料庫服務）上線已經有一段時間，陸續不斷有產品遷入到了RDS中，線上上營運的過程中，也遇到了一些曾經沒有考慮到，或者考慮的不全的東西。後續有時間可以分享給大家。今天想提到的是線上一個4G的RDS執行個體，發生了OOM（out of memory）的問題，MySQL進程被直接Kill掉了。在解釋這個問題的時候，我們首先需要從Linux系統記憶體配置策略講起。   

資料存放區演化思路一：單庫單表單庫單表是最常見的資料庫設計，例如，有一張使用者(user)表放在資料庫db中，所有的使用者都可以在db庫中的user表中查到。資料存放區演化思路二：單庫多表隨著使用者數量的增加，user表的資料量會越來越大，當資料量達到一定程度的時候對user表的查詢會漸漸的變慢，從而影響整個DB的效能。如果使用mysql,

背景：我們在做資料移轉或者拆分的時候，使用Tablespace transcation 這種解決方案時，很有可能就會遇到 從庫複製出錯，報： Last_SQL_Errno: 1146那麼具體錯誤內容可能會有如下：Last_SQL_Error: Error 'Table 'spider.tb_city_population_rank' doesn't exist' on query. Default database: 'spider'. Query: 'alter table

直接切入正題吧:通常來說，我們看到的慢查詢一般還不致於導致掛站，頂多就是應用響應變慢不過這個恰好今天被我撞見了，一個慢查詢把整個網站搞掛了先看看這個SQL張撒樣子：# Query_time: 70.472013 Lock_time: 0.000078 Rows_sent: 7915203 Rows_examined: 15984089 Rows_affected: 0# Bytes_sent: 1258414478use js_sku;SET timestamp=146585