13518219792
出自：
成都创新互联长期为上1000家客户提供的网站建设服务，团队从业经验10年，关注不同地域、不同群体，并针对不同对象提供差异化的产品和服务；打造开放共赢平台，与合作伙伴共同营造健康的互联网生态环境。为邯郸企业提供专业的网站建设、成都做网站，邯郸网站改版等技术服务。拥有十载丰富建站经验和众多成功案例,为您定制开发。
1、配置环境变量
我的电脑-属性-高级-环境变量
选择PATH,在其后面添加: 你的mysql bin文件夹的路径 (如:C:\Program Files\MySQL\MySQL Server 5.6\bin )
PATH=.......;C:\Program Files\MySQL\MySQL Server 5.6\bin (注意是追加,不是覆盖)
2、my.ini文件 （ansc编码）
配置文件是在C:\Program Files\MySQL\MySQL Server 5.6\my.ini，或者自己建立一个my.ini文件，
在其中修改或添加配置（如图）：
[mysqld]
basedir=C:\Program Files\MySQL\MySQL Server 5.6（mysql所在目录）
datadir=C:\Program Files\MySQL\MySQL Server 5.6\data （mysql所在目录\data）
不用新建data文件夹。
3、
以管理员身份运行cmd（一定要用管理员身份运行，不然权限不够），
输入：cd C:\Program Files\MySQL\MySQL Server 5.6\bin 进入mysql的bin文件夹
mysqld -install
继续在cmd中输入:net start mysql
注意：这个时候经常会出现错误2和错误1067。
如果出现“错误2 系统找不到文件”，检查一下是否修改过配置文件或者是否进入在bin目录下操作，如果配置文件修改正确并且进入了bin文件夹，需要先删除mysql（输入 mysqld -remove）再重新安装（输入 mysqld -install）；
如果出现错误1067，那就是配置文件修改错误，确认一下配置文件是否正确。
4、第三步启动时，报错：
mysql无法启动，服务没有报告任何错误
bin下执行：
mysqld --initialize-insecure
会创建data目录。再次启动mysql
5、首次安装的mysql，没有密码
bin下
mysql -u root - p
mysql
设置密码有很多方法：
1.用root 进入mysql后
mysqlset password =password('你的密码');
mysqlflush privileges;
2.使用GRANT语句
mysqlgrant all on . to 'root'@'localhost' IDENTIFIED BY '你的密码'with grant option ;
mysqlflush privileges;
3.进入mysql库修改user表
mysqluse mysql;
mysqlupdate user set password=password('你的密码') where user='root';
mysqlflush privileges;
没有太好的办法，只提到删除重建MySQL数据文件的方式，实际就是备份-删除-恢复的方法，我试验了一下，基本可行，但还是有一些注意事项：
1. 用mysqldump等工具导出数据我的数据库使用latin1字符集
2. 停止 mysqld
3. 删除ibdata*， ib_logfile* 文件
4. 重新启动 mysqld
5. 将导出来的数据导回去，体积才会减小
压缩表从名字上来看，简单理解为压缩后的表，也就是把原始表根据一定的压缩算法按照一定的压缩比率压缩后生成的表。
1.1 压缩能力强的产品
表压缩后从磁盘占用上看要比原始表要小很多。如果你熟悉列式数据库，那对这个概念一定不陌生。比如，基于 PostgreSQL 的列式数据库 Greenplum；早期基于 MySQL 的列式数据库 inforbright；或者 Percona 的产品 tokudb 等，都是有压缩能力非常强的数据库产品。
1.2 为什么要用压缩表？
情景一：磁盘大小为 1T，不算其他的空间占用，只能存放 10 张 100G 大小的表。如果这些表以一定的比率压缩后，比如每张表从 100G 压缩到 10G，那同样的磁盘可以存放 100 张表，表的容量是原来的 10 倍。情景二：默认 MySQL 页大小 16K，而 OS 文件系统一般块大小为 4K，所以在 MySQL 在刷脏页的过程中，有一定的概率出现页没写全而导致数据坏掉的情形。比如 16K 的页写了 12K，剩下 4K 没写成功，导致 MySQL 页数据损坏。这个时候就算通过 Redo Log 也恢复不了，因为几乎有所有的关系数据库采用的 Redo Log 都记录了数据页的偏移量，此时就算通过 Redo Log 恢复后，数据也是错误的。所以 MySQL 在刷脏数据之前，会把这部分数据先写入共享表空间里的 DOUBLE WRITE BUFFER 区域来避免这种异常。此时如果 MySQL 采用压缩表，并且每张表页大小和磁盘块大小一致，比如也是 4K，那 DOUBLE WRITE BUFFER 就可以不需要，这部分开销就可以规避掉了。查看文件系统的块大小：
root@ytt-pc:/home/ytt# tune2fs -l /dev/mapper/ytt--pc--vg-root | grep -i 'block size'Block size: 4096
1.3 压缩表的优势
压缩表的优点非常明显，占用磁盘空间小！由于占用空间小，从磁盘置换到内存以及之后经过网络传输都非常节省资源。
简单来讲：节省磁盘 IO，减少网络 IO。
1.4 压缩表的缺陷
当然压缩表也有缺点，压缩表的写入（INSERT,UPDATE,DELETE）比普通表要消耗更多的 CPU 资源。
压缩表的写入涉及到解压数据，更新数据，再压缩数据，比普通表多了解压和再压缩两个步骤，压缩和解压缩需要消耗一定的 CPU 资源。所以需要选择一个比较优化的压缩算法。
1.5 MySQL 支持的压缩算法
这块是 MySQL 所有涉及到压缩的基础，不仅仅用于压缩表，也用于其它地方。比如客户端请求到 MySQL 服务端的数据压缩；主从之间的压缩传输；利用克隆插件来复制数据库操作的压缩传输等等。
从下面结果可以看到 MySQL 支持的压缩算法为 zlib 和 zstd，MySQL 默认压缩算法为 zlib，当然你也可以选择非 zlib 算法，比如 zstd。至于哪种压缩算法最优，暂时没办法简单量化，依赖表中的数据分布或者业务请求。
