MYSQL常见问题解决集锦
MySQL错误日志里出现：
:08:18 [ERROR] Error reading master configuration
:08:18 [ERROR] Failed to initialize the master info
:08:18 [Note] Event Scheduler: Loaded 0 events
从错误提示就可以看出和mster info相关，找到数据目录下的master.info文件，直接cat查看
# cat master.info&
luocs-mysql-
bin.000004
可以看出格式不对，解决方法非常简单，reset slave即可，这样将会清空master.info文件，错误也将消失。
———————————————————————————————————————————————————————&
MySQL 往一张大表添加字段时报如下错误：
ERROR 1799 (HY000) at line 1: Creating index 'PRIMARY' required
more than 'innodb_online_alter_log_max_size' bytes of modification
log. Please try again.&
解决方法：
我的数据库为MySQL 5.5版本，innodb_online_alter_log_max_size值为默认大小128M。
mysql& show variables like
'innodb_online_alter_log_max_size';
+——————————————+———————-+
| Variable_name & &
& & &| Value
+——————————————+———————-+
| innodb_online_alter_log_max_size &
+——————————————+———————-+
1 rows in set (0.00 sec)
该参数为动态参数且全局的，可通过如下命令加大
mysql& set global
innodb_online_alter_log_max_size=;
Query OK, 0 rows affected (0.03 sec)
加到合适大小，我往120G大小表里添加字段设置该值4G，成功执行。
———————————————————————————————————————————————————————&
MySQL日志：
:03:25 &InnoDB: ERROR: the age of the
last checkpoint is 9434024,
InnoDB: which exceeds the log group capacity 9433498.
InnoDB: If you are using big BLOB or TEXT rows, you must set
InnoDB: combined size of log files at least 10 times bigger than
InnoDB: largest such row.
应该是Innodb引擎下日志大小设置过小导致的，某个事物产生大量日志，但innodb_log_file_size设置过小，可以加大解决。
解决方法：
直接贴网上找到的方法，如下
STEP 01) Change the following in /etc/my.cnf
innodb_log_buffer_size & &
& & &= 32M
innodb_buffer_pool_size & &
innodb_log_file_size & &
STEP 02) mysql -uroot -p -e"SET GLOBAL innodb_fast_shutdown =
STEP 03) service mysql stop
STEP 04) rm -f /var/lib/mysql/ib_logfile*
STEP 05) service mysql start
I added SET GLOBAL innodb_fast_shutdown = 0;. What does that do? It
forces InnoDB to completely purge transactional changes from all of
InnoDB moving parts, including the transactional logs (ib_logfile0,
ib_logfile1). Thus, there is no need to backup the old ib_logfile0,
ib_logfile1. If deleting them makes you nervous, then make Step
mv /var/lib/mysql/ib_logfile* ..
———————————————————————————————————————————————————————&
使用pt-online-schema-change工具添加字段时，收到错误如下：
# pt-online-schema-change &alter="add column tag_common text
default null" &user=root &password=xxxxxxxx D=MYDB,t=MYTB
Cannot connect to D=lsedata_13Q1,h=10.13.7.47,p=…,u=root
No slaves found. &See &recursion-method if host
BJL1-Y13-10-ops.gaoder.net has slaves.
Not checking slave lag because no slaves were found and
&check-slave-lag was not specified.
# A software update is available:
# & * Percona Toolkit 2.2.6 has a possible
security issue (CVE-) upgrade is recommended. The current
version for Percona::Toolkit is 2.2.7.
The table `MYDB`.`MYTB` has triggers. &This tool
needs to create its own triggers, so the table cannot already have
这是MYTB表上之前就有触发器的原因，可以从pt-online-schema-change的工作机制了解到：
如果存在外键，根据alter-foreign-keys-method参数值，检测外键相关的表，针对相应的设置进行处理；
2) 创建一个新的表，表结构修改后的数据表，用于从源数据表向新表中导入数据；
创建触发器，在复制数据开始之后，将对源数据表继续进行数据修改的操作记录下来，以便在数据复制结束后执行这些操作，保证数据不会丢失；
4) 复制数据，从源数据表中复制数据到新表中；
5) 修改外键相关的子表，根据修改后的数据，修改外键关联的子表；
6) 更改源数据表为old表，把新表更改为源表名，并将old表删除；
7) 删除触发器；
pt-online-schema-change详细文档，请阅读：http://www.percona.com/doc/percona-toolkit/2.1/pt-online-schema-change.html
———————————————————————————————————————————————————————&
我们在使用mysqldump的时候可能会遇到如下错误：
mysqldump: Got error: 1044: Access denied for user 'lseread'@'IP'
to database 'lsedata_13q1' when doing LOCK TABLES
解决方法：
加上&skip-lock-tables即可，类似如下：
mysqldump -h1.1.1.1 &-uuser &
-ppassword & -P3306 mydb mytb &where "time &=
cast(' 16:00' as datetime)" &skip-lock-tables
&default-character-set=utf8 &&
MySQL5.6开始提供新特性GTID模式，我们的研发人员在我提供的从库上dump的时候遇到如下警告：
Warning: Using a password on the command line interface can be
Warning: A partial dump from a server that has GTIDs will by
default include the GTIDs of all transactions, even those that
changed suppressed parts of the database. If you don't want to
restore GTIDs, pass &set-gtid-purged=OFF. To make a complete dump,
pass &all-databases &triggers &routines &events.
虽然有警告，但数据还是可以dump出来，郁闷的是，想把dump文件导入到其他版本数据库的时候将会遇到：
ERROR 1839 (HY000) at line 24: @@GLOBAL.GTID_PURGED can only be set
when @@GLOBAL.GTID_MODE = ON.
参考如下文：
gtid_executed:
WHEN used WITH global scope, this variable contains a
representation OF the SET OF ALL transactions that are logged IN
the BINARY log.&
WHEN used WITH SESSION scope, it contains a representation OF the
SET OF transactions that are written TO the cache IN the CURRENT
Issuing RESET MASTER causes the global VALUE (but NOT the SESSION
VALUE) OF this variable TO be reset TO an empty string.
解决方法：
dump的时候加上参数&gtid-mode=OFF，类似如下：
mysqldump -h1.1.1.1 &-uuser &
-ppassword & -P3306 mydb mytb &where "time &=
cast(' 16:00' as datetime)" &skip-lock-tables
&default-character-set=utf8 &gtid-mode=OFF &
———————————————————————————————————————————————————————&
给一张大表添加字段，过了一段时间系统HANG住，添加字段工作中断。系统重启之后，想重新添加字段，却遇到如下错误：
mysql& alter table mytb add column y
ERROR ): Table 'mydb/#sql-ib54' already exists
查看MySQL err日志：
09:10:12 10578 [Note] /opt/mysql5.6/bin/mysqld: ready
for connections.
Version: '5.6.17-log' &socket:
'/opt/mysql5.6/data/mysql.sock' &port: 3307
&Source distribution
09:10:24 10578 [ERROR] InnoDB: Failed to find tablespace
for table '"mydb"."#sql-ib54"' in the cache. Attempting to load the
tablespace with space id 54.
09:10:24 52e55940 &InnoDB: Operating
system error number 2 in a file operation.
InnoDB: The error means the system cannot find the path
specified.
09:10:24 10578 [ERROR] InnoDB: Could not find a valid
tablespace file for 'mydb/#sql-ib54'. See
http://dev.mysql.com/doc/refman/5.6/en/innodb-troubleshooting-datadict.html
for how to resolve the issue.
查看数据目录，有#开头的一些文件，如下：
& 其他表信息忽略，之所以.ibd文件较多是因为操作表mytb为分区表
#sql-ib58.ibd &#sql-ib65.ibd #sql-1935_2.frm
&#sql-ib59.ibd
&#sql-ib66.ibd
#sql-1935_2.par &#sql-ib60.ibd
&#sql-ib67.ibd #sql-ib54.ibd &
&#sql-ib61.ibd
#sql-ib55.ibd & &#sql-ib62.ibd
#sql-ib56.ibd & &#sql-ib63.ibd
#sql-ib57.ibd &
&#sql-ib64.ibd
这个问题我头一次碰到，没深入研究过其中细节，只是想着#开头为临时文件，觉得可以rm，不犹豫直接删掉。
然后重启数据库，结果报了大量ERROR：
09:10:12 2b1b9b20dfe0 &InnoDB:
Operating system error number 2 in a file operation.
InnoDB: The error means the system cannot find the path
specified.
InnoDB: If you are installing InnoDB, remember that you must
InnoDB: directories yourself, InnoDB does not create them.
09:10:12 10578 [ERROR] InnoDB: Could not find a valid
tablespace file for 'mydb/#sql-ib54'. See
http://dev.mysql.com/doc/refman/5.6/en/innodb-troubleshooting-datadict.html
for how to resolve the issue.
09:10:12 10578 [ERROR] InnoDB: Tablespace open failed
for '"mydb"."#sql-ib54"', ignored.
09:10:12 2b1b9b20dfe0 &InnoDB:
Operating system error number 2 in a file operation.
InnoDB: The error means the system cannot find the path
specified.
InnoDB: If you are installing InnoDB, remember that you must
InnoDB: directories yourself, InnoDB does not create them.
09:10:12 10578 [ERROR] InnoDB: Could not find a valid
tablespace file for 'mydb/#sql-ib55'. See
http://dev.mysql.com/doc/refman/5.6/en/innodb-troubleshooting-datadict.html
for how to resolve the issue.
09:10:12 10578 [ERROR] InnoDB: Tablespace open failed
for '"mydb"."#sql-ib55"', ignored.
遇到问题需要淡定，我尝试继续添加字段，但报错依然。
然后我阅读了下错误日志里给出的http://dev.mysql.com/doc/refman/5.6/en/innodb-troubleshooting-datadict.html文章，才了解到，在独立表空间模式下通过shell命令删除表结构和表空间文件的话就会遇到这种问题。
文中还给出了抢救方法，我找到了如下文段：
Problem with Temporary Table
If MySQL crashes in the middle of an ALTER TABLE operation, you may
end up with an orphaned temporary table inside the InnoDB
tablespace. Using the Table Monitor, you can see listed a table
with a name that begins with #sql-. You can perform SQL statements
on tables whose name contains the character “#” if you enclose the
name within backticks. Thus, you can drop such an orphaned table
like any other orphaned table using the method described earlier.
To copy or rename a file in the Unix shell, you need to put the
file name in double quotation marks if the file name contains
我就创建了一个新库，创建了同结构的表，然后再该表上进行添加字段操作，这时候新库数据目录下又产生#sql-开头的文件，我把这些文件全部拷贝到原库目录下。
接着全部改名，如下：
# mv \#sql-2ff9_1.frm sql-2ff9_1.frm
# mv \#sql-2ff9_1.par sql-2ff9_1.par
# mv \#sql-ib82.ibd sql-ib82.ibd&
# mv \#sql-ib83.ibd sql-ib83.ibd&
# mv \#sql-ib84.ibd sql-ib84.ibd&
# mv \#sql-ib85.ibd sql-ib85.ibd&
# mv \#sql-ib86.ibd sql-ib86.ibd&
# mv \#sql-ib87.ibd sql-ib87.ibd&
# mv \#sql-ib88.ibd sql-ib88.ibd&
# mv \#sql-ib89.ibd sql-ib89.ibd&
# mv \#sql-ib90.ibd sql-ib90.ibd&
# mv \#sql-ib91.ibd sql-ib91.ibd&
# mv \#sql-ib92.ibd sql-ib92.ibd&
# mv \#sql-ib93.ibd sql-ib93.ibd&
# mv \#sql-ib94.ibd sql-ib94.ibd&
# mv \#sql-ib95.ibd sql-ib95.ibd&
这样show tables能查看表信息：
+———————+
| Tables_in_mydb & |
+———————+
| #mysql50#sql-2ff9_1 |
+———————+
1 rows in set (0.01 sec)
但悲剧的是，我尝试删除#mysql50#sql-2ff9_1这个表，却始终没能删掉。
时间耗得也不少，开发那边一直在询问进展。
我就想到别的方案：
该表rename，创建结构一样的新表，导数据到新表，再往新表里增加字段，rename的表删除。
实际证明此方案可行。就是数据量大，导数据过程时间长，当然增加字段时间也一样长。
那网上有些人说删除ibdata1和ib_logfile0、1，然后重启数据库就可以解决，这方法可行吗？
答案当然是NO，在独立表空间模式下，ibdata里保存数据字典以及UNDO信息，删除之后重启数据库将会生成全新的ibdata，也就是丢失了字典信息和UNDO了。
到时候会出现如下现象：
+——————-+
| Tables_in_mydb |
+——————-+
| t1 & & &
+——————-+
1 rows in set (0.01 sec)
mysql& select count(*) from t1;
ERROR ): Table 'mydb.t1' doesn't exist
———————————————————————————————————————————————————————&
主从复制失败，查看slave日志如下错误：
140405 &4:16:12 [ERROR] Slave I/O: error
reconnecting to master 'rep1@10.13.34.199:3306' & retry-time: 60
&retries: 86400, Error_code: 2003
140405 &6:53:12 [Note] Slave: connected to
master 'rep1@10.13.34.199:3306',replication resumed in log
'mysql-bin.000275' at position
140405 &6:53:12 [ERROR] Error reading packet
from server: Could not find first log file name in binary log index
file ( server_errno=1236)
140405 &6:53:12 [ERROR] Slave I/O: Got fatal
error 1236 from master when reading data from binary log: 'Could
not find first log file name in binary log index file', Error_code:
140405 &6:53:12 [Note] Slave I/O thread
exiting, read up to log 'mysql-bin.000275', position
140405 &6:54:11 [Note] Error reading relay
log event: slave SQL thread was killed
140405 &6:54:11 [Note] Slave I/O thread:
connected to master 'rep1@10.13.34.199:3306',replication started in
log 'mysql-bin.000275' at position
140405 &6:54:11 [ERROR] Error reading packet
from server: Could not find first log file name in binary log index
file ( server_errno=1236)
140405 &6:54:11 [ERROR] Slave I/O: Got fatal
error 1236 from master when reading data from binary log: 'Could
not find first log file name in binary log index file', Error_code:
140405 &6:54:11 [Note] Slave I/O thread
exiting, read up to log 'mysql-bin.000275', position
140405 &6:54:11 [Note] Slave SQL thread
initialized, starting replication in log 'mysql-bin.000275' at
position , relay log './SHUBEI-34-198-relay-bin.000153'
从指定的binlog里找到指定的position位置，我发现这已经到头了，之后就是切了新binlog
# mysqlbinlog mysql-bin.000275 | grep -A 10
#140405 &3:16:06 server id 1
&end_log_pos
DELIMITER ;
# End of log file
ROLLBACK ;
这下问题好解决了，给从库指定新的binlog即可。
+——————+———-+————&+——————+
| File & &
& | Position | Binlog_Do_DB | Binlog_Ignore_DB
+——————+———-+————&+——————+
| mysql-bin.000276 | & &
&107 | & &
& &| test &
+——————+———-+————&+——————+
1 row in set (0.00 sec)
从库重新配置复制：
Query OK, 0 rows affected (0.00 sec)
mysql& change master to
master_host='10.13.34.199',master_port=3306,master_user='rep1',master_password='RepSlavE&2013',
master_log_file='mysql-bin.000276',master_log_pos=107;&
Query OK, 0 rows affected (0.05 sec)
Query OK, 0 rows affected (0.00 sec)
查看主从复制状态：
mysql& show slave status\G
—-省略—-
&Slave_IO_Running: Yes
Slave_SQL_Running: Yes
———————————————————————————————————————————————————————&
解决ERROR 1872 (HY000): Slave failed to initialize relay log
info structure from the repository
修改了relay-log的输出格式之后，重启MySQL，同步失败
ERROR 1872 (HY000): Slave failed to initialize relay log info
structure from the repository
MySQL Error日志：
16:35:19 27094 [ERROR] Failed to open the relay log
'./luocs166-relay-bin.000007' (relay_log_pos 359).
16:35:19 27094 [ERROR] Could not find target log
file mentioned in relay log info in the index file
'/opt/mysql/data/anav-relay-log.index' during relay log
initialization.
解决方法：
我在查看change master to命令的时候找到如下文段
mysql& ? change master to
& 省略大部分
The next example shows an operation that is less frequently
It is used when the slave has relay log files that you want it
execute again for some reason. To do this, the master need not
reachable. You need only use CHANGE MASTER TO and start the
SQL thread
(START SLAVE SQL_THREAD):
CHANGE MASTER TO
& RELAY_LOG_FILE='slave-relay-bin.006',
& RELAY_LOG_POS=4025;
但我的数据库版本为5.6，使用了GTID模式，使用报错：
mysql& CHANGE MASTER TO
RELAY_LOG_FILE='anav-relay-log.000001',
RELAY_LOG_POS=120;
ERROR 1776 (HY000): Parameters MASTER_LOG_FILE,
MASTER_LOG_POS, RELAY_LOG_FILE and RELAY_LOG_POS cannot be set when
MASTER_AUTO_POSITION is active.
因此如下解决：
Query OK, 0 rows affected (0.00 sec)
mysql& CHANGE MASTER TO
MASTER_HOST='10.19.3.168',
MASTER_USER='repl2',
MASTER_PASSWORD='oracle',
MASTER_AUTO_POSITION = 1;
Query OK, 0 rows affected, 2 warnings (0.02 sec)
Query OK, 0 rows affected, 1 warning (0.01 sec)
mysql& show slave status\G
…. 省略部分 ….
&Slave_IO_Running: Yes
Slave_SQL_Running: Yes
已投稿到：
以上网友发言只代表其个人观点，不代表新浪网的观点或立场。MySQL中的一些特性和SQL语句中需要注意的问题
1、查询数据的编码；
SHOW VARIABLES LIKE '%char%';
2、MySQL中字符与数字转换的方法；
将字符的数字转成数字，比如'0'转成0可以直接用加法实现；
select * from pony order by (d+0)；
3、在mysql中插入多条数据时，values关键字可以省略，直接跟多条数据；
4、union和union all之间的区别和联系；
使用Union，则所有返回的行都是唯一的，如同您已经对整个结果集合使用了DISTINCT
使用Union all，则不会排重，返回所有的行
5、在MySQL中如何进行判断(将数字转换成字符串)；
if(sal&200,'high','low');
ifnull(val,n) 如果val为null值，则返回n；
case sal when 200 then 'low' when 300 then 'high' else 'hehe'
6、Mysql中时间的操作基本方法；
DATE_ADD(NOW(), INTERVAL -30 DAY)，NOW()；
7、Mysql数据库中判断某个字段是否为空；
查询语句：　select * from table
切记不能使用 =null；
8、Mysql中创建约束的常用方式；
PRIMARY KEY (FId))；
FOREIGN KEY (FDepartmentId) REFERENCES T_Department(FId))；
9、mysql中把字符串类型转换成数字类型；
列+0 就可以转换
10、Mysql 怎么把输出转换成百分比形式；
concat(truncate(royalties * 100,2),'%')
TRUNCATE(X,D)；返回被舍去至小数点后D位的数字X。
若D 的值为 0, 则结果不带有小数点或不带有小数部分。
可以将D设为负数,若要截去(归零) X小数点左起第D位开始后面所有低位的值.
11、Mysql中怎么取时间日期的年月日；
date_format(signDate,'%Y-%m');w
看过本文的人也看了：
我要留言技术领域：
取消收藏确定要取消收藏吗？
删除图谱提示你保存在该图谱下的知识内容也会被删除，建议你先将内容移到其他图谱中。你确定要删除知识图谱及其内容吗？
删除节点提示无法删除该知识节点，因该节点下仍保存有相关知识内容！
删除节点提示你确定要删除该知识节点吗？MySQL常见问题解决方案_百度文库
两大类热门资源免费畅读
续费一年阅读会员，立省24元！
MySQL常见问题解决方案
&&MySQL常见问题解决方案
阅读已结束，下载本文需要
想免费下载本文？
定制HR最喜欢的简历
下载文档到电脑，方便使用
还剩1页未读，继续阅读
定制HR最喜欢的简历
你可能喜欢mysql索引必须了解的几个重要问题
转载 & & 作者：xiaoao89757
这篇文章主要介绍了mysql索引必须了解的几个重要问题,分析了MySQL数据库索引的相关概念与使用技巧,需要的朋友可以参考下
本文讲述了mysql索引必须了解的几个重要问题。分享给大家供大家参考，具体如下：
1、索引是做什么的?
索引用于快速找出在某个列中有一特定值的行。不使用索引，MySQL必须从第1条记录开始然后读完整个表直到找出相关的行。
表越大，花费的时间越多。如果表中查询的列有一个索引，MySQL能快速到达一个位置去搜寻到数据文件的中间，没有必要看所有数据。
大多数MySQL索引(PRIMARY KEY、UNIQUE、INDEX和FULLTEXT)在B树中存储。只是空间列类型的索引使用R-树，并且MEMORY表还支持hash索引。
2、索引好复杂，我该怎么理解索引，有没一个更形象点的例子？
有，想象一下，你面前有本词典，数据就是书的正文内容，你就是那个cpu，而索引，则是书的目录
3、索引越多越好？
大多数情况下索引能大幅度提高查询效率，但：
数据的变更（增删改）都需要维护索引，因此更多的索引意味着更多的维护成本
更多的索引意味着也需要更多的空间 （一本100页的书，却有50页目录？）
过小的表，建索引可能会更慢哦 ：）& （读个2页的宣传手册，你还先去找目录？）
4、索引的字段类型问题
text类型，也可建索引（需指定长度）
myisam存储引擎索引键长度综合不能超过1000字节
用来筛选的值尽量保持和索引列同样的数据类型
5、like 不能用索引？
尽量减少like，但不是绝对不可用，"xxxx%" 是可以用到索引的，
想象一下，你在看一本成语词典，目录是按成语拼音顺序建立，查询需求是，你想找以 "一"字开头的成语（"一%"），和你想找包含一字的成语（"%一%"）
除了like，以下操作符也可用到索引：
&，&=，=，&，&=，BETWEEN，IN
&&，not in ，！=则不行
6、什么样的字段不适合建索引？
一般来说，列的值唯一性太小（如性别，类型什么的），不适合建索引（怎样叫太小？一半说来，同值的数据超过表的百分之15，那就没必要建索引了）
太长的列，可以选择只建立部分索引，（如：只取前十位做索引）
更新非常频繁的数据不适宜建索引（怎样叫非常？意会）
7、一次查询能用多个索引吗?
8、多列查询该如何建索引?
一次查询只能用到一个索引，所以 首先枪毙 a，b各建索引方案
a还是b？ 谁的区分度更高（同值的最少），建谁！
当然，联合索引也是个不错的方案，ab，还是ba，则同上，区分度高者，在前
9、联合索引的问题?
where a = "xxx" 可以使用 AB 联合索引
where b = "xxx" 则不可 （再想象一下，这是书的目录？）
所以，大多数情况下，有AB索引了，就可以不用在去建一个A索引了
10、哪些常见情况不能用索引?
like "%xxx"
not in ， !=
对列进行函数运算的情况（如 where md5(password) = "xxxx"）
WHERE index=1 OR A=10
存了数值的字符串类型字段（如手机号），查询时记得不要丢掉值的引号，否则无法用到该字段相关索引，反之则没关系
select * from test where mobile = ;
可是无法用到mobile字段的索引的哦（如果mobile是char 或 varchar类型的话）
btw，千万不要尝试用int来存手机号（为什么？自己想！要不自己试试）
11、覆盖索引(Covering Indexes)拥有更高效率
索引包含了所需的全部值的话，就只select 他们，换言之，只select 需要用到的字段，如无必要，可尽量避免select *
12、NULL 的问题
NULL会导致索引形同虚设，所以在设计表结构时应避免NULL 的存在（用其他方式表达你想表达的NULL，比如 -1？）
13、如何查看索引信息，如何分析是否正确用到索引?
explain select ……;
关于explain，改天可以找个时间专门写一篇入门帖，在此之前，可以尝试 google
14、了解自己的系统，不要过早优化!
过早优化，一直是个非常讨厌而又时刻存在的问题，大多数时候就是因为不了解自己的系统，不知道自己系统真正的承载能力
比如：几千条数据的新闻表，每天几百几千次的正文搜索，大多数时候我们可以放心的去like，而不要又去建一套全文搜索什么的，毕竟cpu还是比人脑厉害太多
15、分享个小案例：
曾经有个朋友找板子，说：大师帮看看，公司网站打不开
板子笑了笑：大师可不敢当啊，待我看看再说
板子花了10分钟分析了下：中小型企业站，量不大（两三万pv每天），独立服务器，数据量不大（100M不到），应该不至于太慢
某个外包团队做的项目，年久失修，彻底改造？不现实！
于是，板子花了20分钟给可以加索引的字段都加上了索引，于是，世界安静了
朋友说：另外一个哥们说，优化至少得2w外包费，你只用30分钟，看来，大师你是当之无愧了，选个最好的餐馆吧
板子：那就来点西餐吧，常熟路地铁站肯德基等你！
16、最后：永远别忘记的关键词 sql注入
希望本文所述对大家MySQL数据库程序设计有所帮助。
您可能感兴趣的文章:
大家感兴趣的内容
12345678910
最近更新的内容
常用在线小工具