連接mysql數據庫crud,連接mysql數據庫錯誤2005

本文目錄一覽：

• 1、如何連接android和php mysql數據庫
• 2、Mysql某個表有近千萬數據，CRUD比較慢，如何優化？
• 3、php做的網站 連接mysql數據庫 效率問題

如何連接android和php mysql數據庫

使用JSON連接Android和PHP Mysql數據庫方法：

1、打開安裝WAMP Server的文件夾，打開www文件夾，為你的項目創建一個新的文件夾。必須把項目中所有的文件放到這個文件夾中。

2、新建一個名為android_connect的文件夾，並新建一個php文件，命名為test.php，嘗試輸入一些簡單的php代碼（如下所示）。

test.php

?php

echo”Welcome, I am connecting Android to PHP, MySQL”;

?

3、創建MySQL數據庫和表

創建了一個簡單的只有一張表的數據庫。用這個表來執行一些示例操作。現在，請在瀏覽器中輸入，並打開phpmyadmin。你可以用PhpMyAdmin工具創建數據庫和表。

創建數據庫和表：數據庫名：androidhive，表：product

CREATE TABLE products(

pid int(11) primary key auto_increment,

name varchar(100) not null,

price decimal(10,2) not null,

description text,

created_at timestamp default now(),

updated_at timestamp

);

4、用PHP連接MySQL數據庫

現在，真正的服務器端編程開始了。新建一個PHP類來連接MYSQL數據庫。這個類的主要功能是打開數據庫連接和在不需要時關閉數據庫連接。

新建兩個文件db_config.php,db_connect.php

db_config.php——–存儲數據庫連接變量

db_connect.php——-連接數據庫的類文件

db_config.php

?php

/*

* All database connection variables

*/

define(‘DB_USER’, “root”); // db user

define(‘DB_PASSWORD’, “”); // db password (mention your db password here)

define(‘DB_DATABASE’, “androidhive”); // database name

define(‘DB_SERVER’, “localhost”); // db server

?

5、在PHP項目中新建一個php文件，命名為create_product.php，並輸入以下代碼。該文件主要實現在products表中插入一個新的產品。

?php

/*

* Following code will create a new product row

* All product details are read from HTTP Post Request

*/

// array for JSON response

$response = array();

// check for required fields

if (isset($_POST[‘name’]) isset($_POST[‘price’]) isset($_POST[‘description’])) {

$name = $_POST[‘name’];

$price = $_POST[‘price’];

$description = $_POST[‘description’];

// include db connect class

require_once __DIR__ . ‘/db_connect.php’;

// connecting to db

$db = new DB_CONNECT();

// mysql inserting a new row

$result = mysql_query(“INSERT INTO products(name, price, description) VALUES(‘$name’, ‘$price’, ‘$description’)”);

// check if row inserted or not

if ($result) {

// successfully inserted into database

$response[“success”] = 1;

$response[“message”] = “Product successfully created.”;

// echoing JSON response

echo json_encode($response);

} else {

// failed to insert row

$response[“success”] = 0;

$response[“message”] = “Oops! An error occurred.”;

// echoing JSON response

echo json_encode($response);

}

} else {

// required field is missing

$response[“success”] = 0;

$response[“message”] = “Required field(s) is missing”;

// echoing JSON response

echo json_encode($response);

}

?

JSON的返回值會是：

當POST 參數丟失

[php] view plaincopy

{

“success”: 0,

“message”: “Required field(s) is missing”

}

Mysql某個表有近千萬數據，CRUD比較慢，如何優化？

數據千萬級別之多，佔用的存儲空間也比較大，可想而知它不會存儲在一塊連續的物理空間上，而是鏈式存儲在多個碎片的物理空間上。可能對於長字符串的比較，就用更多的時間查找與比較，這就導致用更多的時間。

可以做表拆分，減少單表字段數量，優化表結構。

在保證主鍵有效的情況下，檢查主鍵索引的字段順序，使得查詢語句中條件的字段順序和主鍵索引的字段順序保持一致。

主要兩種拆分 垂直拆分，水平拆分。

垂直分表

也就是“大表拆小表”，基於列字段進行的。一般是表中的字段較多，將不常用的， 數據較大，長度較長（比如text類型字段）的拆分到“擴展表“。 一般是針對 那種 幾百列的大表，也避免查詢時，數據量太大造成的“跨頁”問題。

垂直分庫針對的是一個系統中的不同業務進行拆分，比如用戶User一個庫，商品Product一個庫，訂單Order一個庫。 切分後，要放在多個服務器上，而不是一個服務器上。為什麼？ 我們想象一下，一個購物網站對外提供服務，會有用戶，商品，訂單等的CRUD。沒拆分之前， 全部都是落到單一的庫上的，這會讓數據庫的單庫處理能力成為瓶頸。按垂直分庫後，如果還是放在一個數據庫服務器上， 隨着用戶量增大，這會讓單個數據庫的處理能力成為瓶頸，還有單個服務器的磁盤空間，內存，tps等非常吃緊。 所以我們要拆分到多個服務器上，這樣上面的問題都解決了，以後也不會面對單機資源問題。

數據庫業務層面的拆分，和服務的“治理”，“降級”機制類似，也能對不同業務的數據分別的進行管理，維護，監控，擴展等。 數據庫往往最容易成為應用系統的瓶頸，而數據庫本身屬於“有狀態”的，相對於Web和應用服務器來講，是比較難實現“橫向擴展”的。 數據庫的連接資源比較寶貴且單機處理能力也有限，在高並發場景下，垂直分庫一定程度上能夠突破IO、連接數及單機硬件資源的瓶頸。

水平分表

針對數據量巨大的單張表（比如訂單表），按照某種規則（RANGE,HASH取模等），切分到多張表裡面去。 但是這些表還是在同一個庫中，所以庫級別的數據庫操作還是有IO瓶頸。不建議採用。

水平分庫分表

將單張表的數據切分到多個服務器上去，每個服務器具有相應的庫與表，只是表中數據集合不同。 水平分庫分表能夠有效的緩解單機和單庫的性能瓶頸和壓力，突破IO、連接數、硬件資源等的瓶頸。

水平分庫分表切分規則

1. RANGE

從0到10000一個表，10001到20000一個表；

2. HASH取模

一個商場系統，一般都是將用戶，訂單作為主表，然後將和它們相關的作為附表，這樣不會造成跨庫事務之類的問題。 取用戶id，然後hash取模，分配到不同的數據庫上。

3. 地理區域

比如按照華東，華南，華北這樣來區分業務，七牛雲應該就是如此。

4. 時間

按照時間切分，就是將6個月前，甚至一年前的數據切出去放到另外的一張表，因為隨着時間流逝，這些表的數據 被查詢的概率變小，所以沒必要和“熱數據”放在一起，這個也是“冷熱數據分離”。

分庫分表後面臨的問題

事務支持

分庫分表後，就成了分布式事務了。如果依賴數據庫本身的分布式事務管理功能去執行事務，將付出高昂的性能代價； 如果由應用程序去協助控制，形成程序邏輯上的事務，又會造成編程方面的負擔。

跨庫join

只要是進行切分，跨節點Join的問題是不可避免的。但是良好的設計和切分卻可以減少此類情況的發生。解決這一問題的普遍做法是分兩次查詢實現。在第一次查詢的結果集中找出關聯數據的id,根據這些id發起第二次請求得到關聯數據。

跨節點的count,order by,group by以及聚合函數問題

這些是一類問題，因為它們都需要基於全部數據集合進行計算。多數的代理都不會自動處理合併工作。解決方案：與解決跨節點join問題的類似，分別在各個節點上得到結果後在應用程序端進行合併。和join不同的是每個結點的查詢可以並行執行，因此很多時候它的速度要比單一大錶快很多。但如果結果集很大，對應用程序內存的消耗是一個問題。

數據遷移，容量規劃，擴容等問題

來自淘寶綜合業務平台團隊，它利用對2的倍數取余具有向前兼容的特性（如對4取余得1的數對2取余也是1）來分配數據，避免了行級別的數據遷移，但是依然需要進行表級別的遷移，同時對擴容規模和分表數量都有限制。總得來說，這些方案都不是十分的理想，多多少少都存在一些缺點，這也從一個側面反映出了Sharding擴容的難度。

ID問題

一旦數據庫被切分到多個物理結點上，我們將不能再依賴數據庫自身的主鍵生成機制。一方面，某個分區數據庫自生成的ID無法保證在全局上是唯一的；另一方面，應用程序在插入數據之前需要先獲得ID,以便進行SQL路由.

一些常見的主鍵生成策略

UUID

使用UUID作主鍵是最簡單的方案，但是缺點也是非常明顯的。由於UUID非常的長，除佔用大量存儲空間外，最主要的問題是在索引上，在建立索引和基於索引進行查詢時都存在性能問題。

Twitter的分布式自增ID算法Snowflake

在分布式系統中，需要生成全局UID的場合還是比較多的，twitter的snowflake解決了這種需求，實現也還是很簡單的，除去配置信息，核心代碼就是毫秒級時間41位 機器ID 10位 毫秒內序列12位。

跨分片的排序分頁

一般來講，分頁時需要按照指定字段進行排序。當排序字段就是分片字段的時候，我們通過分片規則可以比較容易定位到指定的分片，而當排序字段非分片字段的時候，情況就會變得比較複雜了。為了最終結果的準確性，我們需要在不同的分片節點中將數據進行排序並返回，並將不同分片返回的結果集進行匯總和再次排序，最後再返回給用戶。

php做的網站 連接mysql數據庫 效率問題

你可以把連接的方法寫進類里，讓它形成方法比如

class something {

global $db;

function web_db(){

$this-db = $this-database(); //把連接方法存如屬性里

}

function database($server = ‘localhost’,$root = ‘root’,$pass = ‘****’){

……//這裡寫你的連接方法，及其關聯表操作

}

…//其他方法

} //class end

在你的頁面程序中這樣寫

require_once “web_common.class.php”;//包進你的類文件

$mysql = new something;

在你需要數據查詢或寫入的時候只要調用 $mysql-db;就好了

如上你可以看出，無論你有多少客戶請求數據庫，而數據庫只在載入頁面時連接一次而已，調用 $mysql-db 只是請求程序，請求方法而已，沒有請求數據庫。第一，數據庫連接查詢只有一次；第二無形中也加快了頁面的載入速度。

記住，你做網頁不是給一個人兩個人用的，而是很很很多個，為了保證數據庫的正常使用，在多請求的情況下依然能很好工作，這是個很好的辦法。

最後close是可寫可不寫的，因為當mysql沒有請求時，它會自動關閉。