我也经常遇到这个问题，navicate lite本身确实没有主动保存功能，但它会定时自动保存，这个自动保存功能在首页面的“工具-选项”卡里的“自动保存”可以进行自动保存的周期修改。
让客户满意是我们工作的目标，不断超越客户的期望值来自于我们对这个行业的热爱。我们立志把好的技术通过有效、简单的方式提供给客户，将通过不懈努力成为客户在信息化领域值得信任、有价值的长期合作伙伴，公司提供的服务项目有：域名与空间、雅安服务器托管、营销软件、网站建设、建阳网站维护、网站推广。
：如果对mysql没有绝对的管理权限，只能查看自己的；那么直接打开navicat，右击在打开菜单列表中“转储SQL文件”，然后直接保存就可以了。
打开Navicat，连接到MySQL数据库。 在左侧的导航栏中，找到目标数据库，并右键单击它，选择“新建表”。 在打开的新建表界面中，可以设置表的各种属性，如表名、表的字符集、表的引擎等。
新建表”。设置表的字段名、类型、长度、主键等。点击“保存”按钮，输入表名如：users，最后“确定”。查看users表结构，双击“表”其次双击“users”。向users表中录入数据，直接手动输入数据。点击“+”保存完成录入。
在mysql中导入/导出超大的sql文本文件，我们可以使用很多方法实例，如有：客户端直接命令操作，分块导入，客户端用source命令操作等等。
ENGINE=InnoDB DEFAULT CHARSET=gbk；打开MySQL目录下的my.ini文件，把里面所有的default-character-set选项设为GBK或者GB2312，保存后重启MySQL。mysql数据库安装的时候。选择语言为gbk，这样在数据库中才可以存放中文。
获得上传的图片文件后，使用全局变量_Files来得到上传文件的路径。然后使用file_get_contents方法获得这个文件的二进制数据。最后通过sql把二进制数据保存到对应的图片表，就可以把图片保存到mysql数据库中了。
同样是两种方法，一种用phpMyAdmin（mysql数据库管理）工具，或者mysql命令行。1 用phpMyAdmin工具 从控制面板，选择创建的空数据库，点“管理”，进入管理工具页面。
1、若采用GBK编码，则一个汉字＝2个字节。项目中oracle10g数据库表字段为varchar（n）类型，存英文很简单，只要字母个数不大于n即可。但是对于汉字，按照同样的方法就不行了。
2、字符集为 utf8mb4 的情况下，测试了下 varchar(64) ，64 就是代表字符长度，就是说可以存储（insert into) 64 个字符（无论中文还是英文）。汉字的话，占用了 64 * 3 个字节，英文的话占用了 64 * 1 个字节。
3、字段的限制在字段定义的时候有以下规则：a) 存储限制 varchar 字段是将实际内容单独存储在聚簇索引之外，内容开头用1到2个字节表示实际长度（长度超过255时需要2个字节），因此最大长度不能超过65535。
4、在字符集为 UTF-8 的情况下：MySQL | version 1 ：VARCHAR以字节为单位存储，假设全部为常用汉字，则VARCHAR(255)共可存放约85个汉字。
5、版本以上，varchar(50)，指的是50字符，无论存放的是数字、字母还是UTF8汉字（每个汉字3字节），都可以存放50个。
6、从MySQL1开始，varchar (N)中的N指的是该字段最多能存储多少个字符(characters)，不是字节数。 不管是一个中英文字符或者数字、或者一个汉字，都当做一个字符。在1之前，N表示的是最大存储的字节数（bytes）。
1、当保存时，在右侧填充空格以达到指定的长度。M 表示列的长度，范围是 0～255 个字符。例如，CHAR(4) 定义了一个固定长度的字符串列，包含的字符个数最大为 4。当检索到 CHAR 值时，尾部的空格将被删除。
2、TEXT列有一个字符集，并且根据字符集的校对规则对值进行排序和比较。
3、最后强调：varchar类型实际占用的空间为字符串的实际长度加1 如varchar(10)：字段 ‘123’，他占的内存字节是4（3+1），而char(10)则占用了10个字节。
4、最多可以存放65535个字符。除此之外MySQL中用于存放大量文本的数据类型还有：varchar：最多可以存放65535个字符。mediumtext：可变长度，最多2的24次方-1个字符。longtext：可变长度，最多2的32次方-1个字符。
5、部分系统使用的字符集是 utf8，但 utf8 最多只能存 3 字节长度的字符，不能存放 4 字节的生僻字或者表情符号，因此打算迁移到 utf8mb4。
6、)，我自己的经验是slash并没有真的被保存，取出数据后解压一点问题没有。将二进制的文件保存在数据库就这样。如果实在不放心，压缩后用base64_encode()，会增加1/3的量，但如果文本很长，这或许是可以忍受的。
