MySQL

偶爾要用到php做一些mysql資料庫的操作測試，自己寫起來太麻煩，搜尋的結果一般都又包含一大堆沒用的代碼，這裡將php mysql的操作做一下總結，希望以後用到的時候不用再感到麻煩了。複製代碼 代碼如下:<?php$dbhost='localhost';//資料庫伺服器名稱$dbuser='root';// 串連資料庫使用者名稱$dbpass='123456';// 串連資料庫密碼$dbname='products';// 資料庫的名字//

首先我們需要瞭解下查詢MySQL資料庫/表相關資訊的SQL語句：複製代碼 代碼如下:SHOW DATABASES                                //

Python的MySQLdb模組是Python串連MySQL的一個模組，預設查詢結果返回是tuple類型，只能通過0,1..等索引下標訪問資料預設串連資料庫：複製代碼 代碼如下:MySQLdb.connect(    host=host,        user=user,        passwd=passwd, 

php封裝mysql類複製代碼 代碼如下:<?php class Mysql { private $host; private $user; private $pwd; private $dbName; private $charset; private $conn = null; public function __construct() {  $this->host =

最佳化前：select count(t.id) from test t where t.status = 1 and t.id not in (select distinct a.app_id from test2 a where a.type = 1 and a.rule_id in (152, 153, 154)) 17:20:57 laojiu>@planPLAN_TABLE_OUTPUT——————————

通常應用需要對錶中的資料進行翻頁，如果資料量很大，往往會帶來效能上的問題：root@sns 07:16:25>select count(*) from reply_0004 where thread_id = 5616385 and deleted = 0;+———-+| count(*) |+———-+| 1236795 |+———-+1 row in set (0.44 sec)root@sns 07:16:30>select idfrom reply_0004 where

在5.1.46中最佳化器在對primary key的選擇上做了一點改動：Performance: While looking for the shortest index for a covering index scan, the optimizer did not consider the full row length for a clustered primary key, as in InnoDB. Secondary covering indexes will now be

安裝環境：作業系統：suse Linux 10資料庫：MySQL 5.0.22希望能認識更多高手，互相學習討論技術！首先發泄一下再這，網上看了N多安裝mysql的文章，大多大同小異，都不能很好的安裝mysql；多多少少都有問題；以個人之見大多為一份原文，拷貝到各自的部落格或一些網上，純屬盜竊啊！上周末開始籌劃安裝suse以及mysql，一直到今天下午才終於到了show

有這樣的一個需求：select count(distinct nick) from user_access_xx_xx;這條sql用於統計使用者訪問的uv，由於單表的資料量在10G以上，即使在user_access_xx_xx上加上nick的索引，通過查看執行計畫，也為全索引掃描，sql在執行的時候，會對整個伺服器帶來抖動；root@db 09:00:12>select count(distinct nick) from user_access;+———————-+|

使用過oracle或者其他關聯式資料庫的DBA或者開發人員都有這樣的經驗，在子查詢上都認為資料庫已經做過最佳化，能夠很好的選擇驅動表執行，然後在把該經驗移植到mysql資料庫上，但是不幸的是，mysql在子查詢的處理上有可能會讓你大失所望，在我們的生產系統上就由於碰到了這個問題：select i_id, sum(i_sell) as i_sellfrom table_datawhere i_id in (select i_id from table_data where Gmt_create &

昨晚收到客服MM電話，一使用者反饋資料庫響應非常慢，手機收到load異常警示，登上主機後發現大量sql執行非常慢，有的執行時間超過了10s最佳化點一：SELECT * FROM `sitevipdb`.`game_shares_buy_list` WHERE price>='2.00′ ORDER BY tran_id DESC LIMIT 10;表結構為：CREATE TABLE `game_shares_buy_list` (`tran_id` int(10) unsigned

昨天處理了一則複雜關聯SQL的最佳化，這類SQL的最佳化往往考慮以下四點：    第一.查詢所返回的結果集，通常查詢返回的結果集很少，是有信心進行最佳化的；    第二.驅動表的選擇至關重要，通過查看執行計畫，可以看到最佳化器選擇的驅動表,從執行計畫中的rows可以大致反映出問題的所在；    第三.理清各表之間的關聯關係，注意關聯欄位上是否有合適的索引；   

Order by desc/asc limit M是我在mysql sql最佳化中經常遇到的一種情境，其最佳化原理也非常的簡單，就是利用索引的有序性，最佳化器沿著索引的順序掃描，在掃描到合格M行資料後，停止掃描；看起來非常的簡單，但是我經常看到很多效能較差的sql沒有利用這個最佳化規律，下面將結合一些實際的案例來分析說明：案例一：一條sql執行非常的慢，執行時間為：root@test 02:00:44 SELECT * FROM test_order_desc WHERE

mysql的子查詢的最佳化一直不是很友好，一直有受業界批評比較多,也是我在sql最佳化中遇到過最多的問題之一，你可以點擊這裡 ，這裡來獲得一些資訊，mysql在處理子查詢的時候，會將子查詢改寫,通常情況下，我們希望由內到外，也就是先完成子查詢的結果，然後在用子查詢來驅動外查詢的表，完成查詢，但是恰恰相反，子查詢不會先被執行；今天希望通過介紹一些實際的案例來加深對mysql子查詢的理解：案例：使用者反饋資料庫響應較慢，許多業務動更新被卡住；登入到資料庫中觀察，發現長時間執行的sql；| 10437

在oracle中可以指定的表串連的hint有很多：ordered hint 指示oracle按照from關鍵字後的表順序來進行串連；leading hint 指示查詢最佳化工具使用指定的表作為串連的首表，即驅動表；use_nl hint指示查詢最佳化工具使用nested loops方式串連指定表和其他行源，並且將強制指定表作為inner表。在mysql中就有之對應的straight_join,由於mysql只支援nested

寫在前面：discuz!作為首屈一指的社區系統，為廣大站長提供了一站式網站解決方案，而且是開源的（雖然部分代碼是加密的），它為這個垂直領域的行業發展作出了巨大貢獻。儘管如此，discuz!系統源碼中，還是或多或少有些坑。其中最著名的就是預設採用MyISAM引擎，以及基於MyISAM引擎的搶樓功能，session表採用memory引擎等，可以參考後面幾篇曆史文章。本次我們要說說discuz!在應對熱們文章翻頁邏輯功能中的另一個問題。在我們的環境中，使用的是 MySQL-5.6.6

收到一個mysql伺服器負載警示，上去一看，load average都飆到280多了，用top一看，CPU跑到了336%，不過IO和記憶體的負載並不高，根據經驗，應該又是一起索引引起的慘案了。看下processlist以及slow query情況，發現有一個SQL經常出現，執行計畫中的掃描記錄數看著還可以，單次執行耗時為0.07s，還不算太大。乍一看，可能不是它引發的，但出現頻率實在太高，而且執行計畫看起來也不夠完美：mysql> explain SELECT count(1) FROM

前段時間，一大早上，就收到警示，警告php-fpm進程的數量超過閾值。最終發現是一條sql沒用到索引，導致執行資料庫查詢慢了，最終導致php-fpm進程數增加。最終通過analyze table feed_comment_info_id_0000 命令更新了Cardinality ，才能再次用到索引。排查過程如下：sql語句：select id from feed_comment_info_id_0000 where obj_id=101 and type=1;索引資訊：show index

我們在工作中時常會遇到一些客戶的TPS\QPS都不太高,但磁碟佔用非常大,一旦單一實例空間太大，像記憶體、網路、CPU以及備份都將增加相應的開銷。可能僅僅是由於空間不滿足使得我們不得不進行擴容，下面的方法提供給大家參考。有則改之無則加勉。1、表結構設計上1) 字元集是否遵循了最小化原則?(能用latin的就不用gbk。能用gbk的就不用utf8)2) 索引上是否有濫用？(根本不使用的欄位建索引、不適合建索引的欄位建索引、重複建索引或者不能很好的利用首碼索引等)3)

當用到socket來進行網路程式開發時，大多數情況下會遇到中文字元的發送與接收，這時若對發送的字串用預設的方式進行處理，則一般會得到一堆亂碼。由於中文字元採用雙位元組表示，所以對含有中文的字串的處理一定要按UNICODE編碼方式進行處理，也就是說，使用socket發送中文字串時要事先將字串轉成UNICODE格式的。下面是簡單的socket通訊的代碼。//服務端代碼 try{ IPAddress MyIP = IPAddress.Parse(“127.0.0.1″); TcpListener