mysql讀取資料庫時間,mysql查看資料庫創建時間

本文目錄一覽：

• 1、mysql中如何查看資料庫表的創建時間？
• 2、mysql查詢資料庫時間怎麼查
• 3、Mysql資料庫中的時間精確到秒，取出數據時想要精確到日
• 4、mysql怎麼查看資料庫的時間
• 5、mysql資料庫響應超時怎麼辦

mysql中如何查看資料庫表的創建時間？

方法：

查看資料庫表的創建時間可以在information_schema中查看

information_schema資料庫表說明:

SCHEMATA表：提供了當前mysql實例中所有資料庫的信息。是show

databases的結果取之此表。

TABLES表：提供了關於資料庫中的表的信息（包括視圖）。詳細表述了某個表屬於哪個schema，表類型，表引擎，創建時間等信息。是show

tables

from

schemaname的結果取之此表。

資料庫表的創建時間在TABLES表中的CREATE_TIME欄位

SELECT CREATE_TIME FROM TABLES WHERE TABLE_SCHEMA=’資料庫名’ AND TABLE_NAME=’表名’;

將上面的資料庫名以及表名替換為所要查詢的數據即可。

mysql查詢資料庫時間怎麼查

方法一：傳統方式，即指定開始時間和結束時間，用”between」或者””，””來建立條件，比如查詢2010年3月1日到2010年3月2日的數據條數，則可以使用

複製代碼 代碼如下:

select count(*) from sometable where datetimecolumn=’2010-03-01 00:00:00′ and datetimecolumn’2010-03-02 00:00:00′

但是，這種方法由於時間不是整數型數據，所以在比較的時候效率較低，所以如果數據量較大，可以將時間轉換為整數型的UNIX時間戳，這就是方法二。

Mysql資料庫中的時間精確到秒，取出數據時想要精確到日

在java也頁面：

SimpleDateFormat sDateFormat = new SimpleDateFormat(“yyyy/MM/dd “); //時間格式化的格式

String nowTimeStr = sDateFormat.format(new Date()); //當前時間,換成資料庫的時間就行了

如果要在jsp頁面，就用

fmt:formatDate value=”你的時間” pattern=”yyyy-MM-dd” type=”date” dateStyle=”long” /就ok了注意引入fmt：%@ taglib uri=”” prefix=”fmt” %

mysql怎麼查看資料庫的時間

首先通過運行資料庫客戶端管理軟體SQLyogEnt進行查詢，第一步運行SQLyogEnt，在桌面找到SQLyogEnt的軟體圖標，用戶雙擊這個圖標。

2.然後輸入資料庫的信息，在界面左下角點擊【連接】按鈕，連接資料庫。

3.連接上資料庫後就進入了資料庫管理軟體的控制台，控制台的左側以目錄的形式顯示了當前登錄的用戶和資料庫以及資料庫的表。目錄的右邊從上到下有2個空白的長方形框，上方的是SQL查詢語言的輸入框，下方顯示的是查詢所得到的結果。

4.有時候一個資料庫IP新建了多個資料庫，在查詢前要用數據在控制台左側目錄上選擇需要操作的資料庫，然後在進行查詢。

5.上面說道了SQL的長方形空白的輸入框，現在我們對資料庫表進行一次查詢吧。如果要查詢一個表中所有的信息可以輸入：SELECT * FROM TABLE_Name

6.查詢表中的某一條數據：SELECT * FROM Table_Name WHERE id=XXXX  注意這裡的id選擇表中的唯一鍵，就是用於標識這條數據與其他數據不同的欄位

顯示某個欄位的數據信息：如name

SELECT name FROM Table_Name WHERE id=XXXX

7.大家在使用時需要對一個表中的數據進行統計可以使用：

SELECT COUNT(*) FROM Tabele_Name

統計某一個條件的數據：如下方的統計表中年齡欄位16歲的所有記錄數

SELECT COUNT(*) FROM Tabele_Name where age=16

統多個條件的數據：如下方的統計表中年齡欄位16歲和班級為3班的所有記錄數

SELECT COUNT(*) FROM Tabele_Name where age=16 and class=3

mysql資料庫響應超時怎麼辦

MYSQL_OPT_READ_TIMEOUT 是 MySQL c api 客戶端中用來設置讀取超時時間的參數。在 MySQL 的官方文檔中，該參數的描述是這樣的：

MYSQL_OPT_READ_TIMEOUT (argument type: unsigned int *)The timeout in seconds for each attempt to read from the server. There are retries if necessary, so the total effective timeout value is three times the option value. You can set the value so that a lost connection can be detected earlier than the TCP/IPClose_Wait_Timeout value of 10 minutes.

也就是說在需要的時候，實際的超時時間會是設定值的 3 倍。但是實際測試後發現實際的超時時間和設置的超時時間一致。

而具體什麼時候發生三倍超時，在文檔中沒有找到。所以對 MySQL 5.7.20 的源碼進行了一些分析。

使用 GDB 調試代碼找了實際與 mysql server 通信的代碼，如下：

請點擊輸入圖片描述

其中 vio_read() 函數中，使用 recv 和 poll 來讀取報文和做讀取超時。net_should_retry() 函數只有在發生 EINTR 時才會返回 true。從這段代碼來看是符合測試結果的，並沒有對讀取進行三次重試。只有在讀取操作被系統中斷打斷時才會重試，但是這個重試並沒有次數限制。

從上面代碼的分析可以看出，代碼的邏輯和文檔的描述不符。於是在一頓搜索後，找到了一個 MySQL 的 BUG(Bug #31163)。該 BUG 報告了在 MySQL 5.0 中，MySQL c api 讀取的實際超時時間是設置的三倍，與現有文檔描述相符。於是對 MySQL 5.0.96 的代碼又進行分析。

同樣使用 GDB 找到了通信部分的代碼。這次找到了重試三次的代碼，如下：

請點擊輸入圖片描述

這個版本的 MySQL api 的讀寫超時是直接使用的 setsockopt 設置的。第一次循環，在 A 點發生了第一次超時（雖然注釋寫的非阻塞，但是客戶端的連接始終是阻塞模式的）。然後在 B 點將該 socket 設置為阻塞模式，C 點這裡重置 retry 次數。由於設置了 alarm 第二次以後的循環會直接進入 D 點的這個分支，並且判斷循環次數。作為客戶端時net-retry_count 始終是 1，所以重試了兩次，共計進行了 3 次 vioread 後從 E 點退出函數。

由上面的分析可知，MySQL 文檔對於該參數的描述已經過時，現在的 MYSQL_OPT_READ_TIMEOUT 並不會出現三倍超時的問題。而 Bug #31163 中的處理結果也是將文檔中該參數的描述更新為實際讀取超時時間是設定時間的三倍。也許是 MySQL 的維護者們在後續版本更新時忘記更新文檔吧。