189 8069 5689
很明显时你创建表的语句出错了。你把创建表的语句发出来，即使大家看见了也不会暴露你的机密的，但是大家必须得看见才知道错误在那里。
专注于为中小企业提供成都网站设计、做网站、成都外贸网站建设公司服务,电脑端+手机端+微信端的三站合一,更高效的管理,为中小企业化州免费做网站提供优质的服务。我们立足成都，凝聚了一批互联网行业人才，有力地推动了1000+企业的稳健成长，帮助中小企业通过网站建设实现规模扩充和转变。
另外你随便找个翻译软件翻译一下就知道了，这段英语说的是你语句错误，不是MYSQL错误。
方法一：1、打开my.ini文件，找到default-storage-engine=InnoDB这一行，把它改成default-storage-engine=MyISAM。2、删除在MySQL安装目录下的Data目录中的ib_logfile0和ib_logfile13。找到在配置MySQL服务器时指定的InfoDB目录删除掉ibdata1根据my.ini文件中：#***INNODBSpecificoptions***innodb_data_home_dir="D:/"。4。重新启动MySQL的Service方法二：重装mysql时，一直提示“无法启动MYSQL服务，错误1067进程意外终止重启，修复注册表都没什么用，网上查了，改什么basedir,也没用我用的是mysql5.8,找来找去，想起之前装了wampserver,pc_webserver等集成环境，此些软件会把my.ini,php.ini写入C:WINDOWS目录下，并设为只读解决方法：把windows目录下，my.ini文件删除，重装mysql,服务启动成功
方法/步骤
1
下载最新MYSQL数据库安装文件，打开下载的mysql安装文件mysql-5.0.27-win32.zip，双击解压缩，运行“setup.exe”，出现如下界面：然后按“Next”继续，选择安装类型，有“Typical（默认）”、“Complete（完全）”、“Custom（用户自定义）”三个选项，我们选择“Typical”，以简化安装过程。点击“Next”进行下一步，可根据自己的需要点击“Change”来自定义安装目录
2
点击“Next”进行下一步，确认一下先前的设置，如果有误，按“Back”返回重做。按“Install”开始安装；现在软件安装完成了，出现上面的界面，这里有一个很好的功能，mysql配置向导，不用向以前一样，自己手动乱七八糟的配置my.ini了，将 “Configure the Mysql Server now”前面的勾打上，点“Finish”结束软件的安装并启动mysql配置向导；
3
启动MYSQL配置向导，然后选择配置方式，“Detailed Configuration（手动精确配置）”、“Standard Configuration（标准配置）”，我们选择“Standard Configuration”，以简化配置过程。选择服务器类型，“Developer Machine（开发测试类，mysql占用很少资源）”、“Server Machine（服务器类型，mysql占用较多资源）”、“Dedicated MySQL Server Machine（专门的数据库服务器，mysql占用所有可用资源）”，建议选择“Server Machine”
4
选择mysql数据库的大致用途，“Multifunctional Database（通用多功能型，好）”、“Transactional Database Only（服务器类型，专注于事务处理，一般）”、“Non-Transactional Database Only（非事务处理型，较简单，主要做一些监控、记数用，对MyISAM数据类型的支持仅限于non-transactional），建议选择“Multifunctional Database”， 按“Next”继续。 对InnoDB Tablespace进行配置，就是为InnoDB 数据库文件选择一个存储空间，如果修改了，要记住位置，重装的时候要选择一样的地方，否则可能会造成数据库损坏，当然，对数据库做个备份就没问题了，这里不详述。我这里没有修改，使用用默认位置，直接按“Next”继续
5
选择您的数据库mysql访问量，同时连接的数目，“Decision Support(DSS)/OLAP（20个左右）”、“Online Transaction Processing(OLTP)（500个左右）”、“Manual Setting（手动设置，自己输一个数）”，按“Next”继续； 选择是否启用TCP/IP连接，设定端口，如果不启用，就只能在自己的机器上访问mysql数据库了，我这里启用，把前面的勾打上，Port Number：3306，在这个页面上，您还可以选择“启用标准模式”（Enable Strict Mode），按“Next”继续。 对mysql默认数据库语言编码进行设置，第一个是西文编码，第二个是多字节的通用utf8编码，都不是我们通用的编码，这里选择第三个，然后在Character Set那里选择或填入“gbk” 选择是否将mysql安装为windows服务，还可以指定Service Name（服务标识名称），是否将mysql的bin目录加入到Windows PATH（加入后，就可以直接使用bin下的文件，而不用指出目录名，比如连接，“mysql.exe -uusername -ppassword;”就可以了，不用指出mysql.exe的完整地址，很方便），我这里全部打上了勾，Service Name不变。按“Next”继续。
6
这一步询问是否要修改默认root用户（超级管理）的密码（默认为空），“New root password”如果要修改，就在此填入新密码，请记好此密码，在配置博一短信平台数据库连接时需要用到这个密码；“Enable root access from remote machines（是否允许root用户在其它的机器上登陆，为了安全，建议不要勾上，“Create An Anonymous Account（新建一个匿名用户，匿名用户可以连接数据库，不能操作数据，包括查询）”，一般就不用勾了，设置完毕，按“Next”继续； 确认设置无误，如果有误，按“Back”返回检查。按“Execute”使设置生效。设置完毕，按“Finish”结束mysql的安装与配置
MySQL选了个不恰当索引而导致的慢查询。
某晚收到了线上数据库的频繁报警，数据库突然大量慢查询，导致每个数据库连接执行一个慢查询都要耗费很久。这还导致突然过来的很多查询需要让MySQL开辟更多连接，因此报警也告诉我们，数据库的连接剧增，而且每个连接都打满，每个连接都要执行一个慢查询。
接着DB的连接全部打满，无法开辟新连接，但还持续的有新的查询请求，导致DB无法处理新查询，很多查询发到DB直接就阻塞然后超时，导致商品系统频繁的报警，出现大量DB查询超时报错的异常。
这意味着商品数据库及商品系统濒临崩溃，大量慢查询耗尽DB连接资源，而且一直阻塞在数据库里执行，数据库没法执行新的查询，商品数据库无法执行查询，用户没法使用商品系统，也就没法查询和筛选电商网站里的商品了。
报警时机又正是晚高峰，虽说商品数据有多级缓存架构，但下单过程中，还是会大量请求商品系统，所以晚高峰时，商品系统本身TPS大致几千。因此发现数据库的监控里显示每min的慢查询超过10w+：商品系统大量的查询都变成了慢查询。
慢查询主要就是如下语句：
该语句执行的商品表里大致1亿左右数据量，该量级已稳定很长时间，主要也就是这么多商品，但上面语句居然一执行就是几十s！基本上数据库的连接全部被慢查询打满，一个连接要执行几十s的SQL，然后才能执行下一个SQL，此时数据库基本就废了，没法执行什么查询。所以商品系统本身也报警查询数据库的超时异常。
经常用到的查询字段肯定都建了索引，即index_category(catetory,sub_category)肯定存在。因为如果你一旦用上了品类索引，按品类和子类去在索引里筛选：
理论上执行速度很快，即使表有亿级数据，但也不应超过1s。但跑了几十秒，说明肯定没用那个索引，看执行计划：
possible_keys=index_category的，key=PRIMARY，Extra=Using where
就是在扫描主键索引，还用where条件里的两个字段做筛选，所以这么扫描就会耗费几十s。
为快速解决问题，使用force index语法，强制改变MySQL自动选择不恰当聚簇索引进行扫描的行为：
再次执行SQL，仅耗费100多ms。
所以若MySQL使用了错误的执行计划，那就force index语法改变它。
但案例还有问题：
该表是个亿级数据量大表，那index_category二级索引也比较大，所以此时MySQL觉得如果从index_category二级索引查找符合where条件的一波数据，接着还得回表。因为要select *，所以必然涉及回表，但在回表前，必然要做完order by id desc limit xx,xx操作。
举个例子，根据where category='xx' and sub_category='xx'，从index_category二级索引里查找出一波数据，假设几万条，
因为二级索引包含主键id，就得按order by id desc，对这几万条数据基于临时磁盘文件进行filesort磁盘排序，排序后，再按limit xx,xx语法将指定位置的几条数据拿出来，假设limit 0,10，那么就是把10条数据拿出来。拿出来10条数据之后，再回到聚簇索引根据id查，把这10条数据的完整字段都查出来，这就是MySQL认为如果你使用index_category的话，可能会发生的一个情况。
所以他担心，你根据
从index_category二级索引里查出来的数据太多了，还得在临时磁盘里排序，可能性能很差，因此MySQL就把这种方式判定不太好。
因此他选择直接扫描主键的聚簇索引，因为聚簇索引按id值有序，所以扫描时，直接按order by id desc倒序得顺序扫描即可，然后因为他知道你是
也就知道你仅仅只要拿到10条数据就行了。所以他在按序扫描聚簇索引时，就会对每条数据都采用Using where，跟
条件进行比对，符合条件的就直接放入结果集里去，最多就是放10条数据进去就可以返回了。
此时MySQL认为，按顺序扫描聚簇索引，拿到10条符合where条件的数据，应该很快，很可能比使用index_category二级索引更快，因此此时他就采用了扫描聚簇索引的这种方式。
这SQL之前在线上系统运行一直没问题，即之前在线上系统而言，即使采用扫描聚簇索引，该SQL也确实运行不慢，最起码是不会超过1s。
为何突然大量报慢查询，耗时几十s？因为之前
条件通常有返回值，即根据条件里的取值，扫描聚簇索引，通常都是很快就能找到符合条件的值并返回，所以之前其实性能也没啥问题。
但后来可能是商品系统里的运营人员，在商品管理的时候加了几种商品分类和子类，但是这几种分类和子类的组合其实没有对应的商品，导致很多用户使用这种分类和子类去筛选商品
条件实际上是查不到任何数据的！所以扫描聚簇索引时，怎么都扫不到符合条件的结果，一下就把聚簇索引全部扫了一遍，等于上亿数据全表扫描一遍，都没找到符合where category='新分类' and sub_category='新子类'这个条件的数据。
正因如此，才导致这个SQL语句频繁的出现几十秒的慢查询，进而导致MySQL连接资源打满，商品系统崩溃！
SQL调优并不太难，核心是看懂SQL执行计划，理解慢的原因，然后想法解决，本案例就得通过force index语法来强制某个SQL用我们指定的索引。
开始--运行--cmd--cd到命令所在目录--输入mysql.exe
再登录看看、这样就可以看到错误提示了。
要先确认：mysql服务是否开启，端口是否开放，root默认密码是否修改了一下。