作者：Lightning@小宝
发布时间：November 26, 2009
分类：MySQl学习笔记
armscii8 (ARMSCII-8 Armenian)
armscii8_bin 亚美尼亚语, 二进制
armscii8_general_ci 亚美尼亚语, 不区分大小写
ascii (US ASCII)
ascii_bin 西欧 (多语言), 二进制
ascii_general_ci 西欧 (多语言), 不区分大小写
big5 (Big5 Traditional Chinese)
big5_bin 繁体中文, 二进制
big5_chinese_ci 繁体中文, 不区分大小写
binary (Binary pseudo charset)
binary 二进制
cp1250 (Windows Central European)
cp1250_bin 中欧 (多语言), 二进制
cp1250_croatian_ci 克罗地亚语, 不区分大小写
cp1250_czech_cs 捷克语, 区分大小写
cp1250_general_ci 中欧 (多语言), 不区分大小写
cp1251 (Windows Cyrillic)
cp1251_bin 西里尔语 (多语言), 二进制
cp1251_bulgarian_ci 保加利亚语, 不区分大小写
cp1251_general_ci 西里尔语 (多语言), 不区分大小写
cp1251_general_cs 西里尔语 (多语言), 区分大小写
cp1251_ukrainian_ci 乌克兰语, 不区分大小写
cp1256 (Windows Arabic)
cp1256_bin 阿拉伯语, 二进制
cp1256_general_ci 阿拉伯语, 不区分大小写
cp1257 (Windows Baltic)
cp1257_bin 巴拉克语 (多语言), 二进制
cp1257_general_ci 巴拉克语 (多语言), 不区分大小写
cp1257_lithuanian_ci 立陶宛语, 不区分大小写
cp850 (DOS West European)
cp850_bin 西欧 (多语言), 二进制
cp850_general_ci 西欧 (多语言), 不区分大小写
cp852 (DOS Central European)
cp852_bin 中欧 (多语言), 二进制
cp852_general_ci 中欧 (多语言), 不区分大小写
cp866 (DOS Russian)
cp866_bin 俄语, 二进制
cp866_general_ci 俄语, 不区分大小写
cp932 (SJIS for Windows Japanese)
cp932_bin 日语, 二进制
cp932_japanese_ci 日语, 不区分大小写
dec8 (DEC West European)
dec8_bin 西欧 (多语言), 二进制
dec8_swedish_ci 瑞典语, 不区分大小写
euckr (EUC-KR Korean)
euckr_bin 朝鲜语, 二进制
euckr_korean_ci 朝鲜语, 不区分大小写
gb2312 (GB2312 Simplified Chinese)
gb2312_bin 简体中文, 二进制
gb2312_chinese_ci 简体中文, 不区分大小写
gbk (GBK Simplified Chinese)
gbk_bin 简体中文, 二进制
gbk_chinese_ci 简体中文, 不区分大小写
geostd8 (GEOSTD8 Georgian)
geostd8_bin 乔治亚语, 二进制
geostd8_general_ci 乔治亚语, 不区分大小写
greek (ISO 8859-7 Greek)
greek_bin 希腊语, 二进制
greek_general_ci 希腊语, 不区分大小写
hebrew (ISO 8859-8 Hebrew)
hebrew_bin 希伯来语, 二进制
hebrew_general_ci 希伯来语, 不区分大小写
hp8 (HP West European)
hp8_bin 西欧 (多语言), 二进制
hp8_english_ci 英语, 不区分大小写
keybcs2 (DOS Kamenicky Czech-Slovak)
keybcs2_bin 捷克斯洛伐克语, 二进制
keybcs2_general_ci 捷克斯洛伐克语, 不区分大小写
koi8r (KOI8-R Relcom Russian)
koi8r_bin 俄语, 二进制
koi8r_general_ci 俄语, 不区分大小写
koi8u (KOI8-U Ukrainian)
koi8u_bin 乌克兰语, 二进制
koi8u_general_ci 乌克兰语, 不区分大小写
latin1 (cp1252 West European)
latin1_bin 西欧 (多语言), 二进制
latin1_danish_ci 丹麦语, 不区分大小写
latin1_general_ci 西欧 (多语言), 不区分大小写
latin1_general_cs 西欧 (多语言), 区分大小写
latin1_german1_ci 德语 (字典), 不区分大小写
latin1_german2_ci 德语 (电话本), 不区分大小写
latin1_spanish_ci 西班牙语, 不区分大小写
latin1_swedish_ci 瑞典语, 不区分大小写 <>
latin2 (ISO 8859-2 Central European)
latin2_bin 中欧 (多语言), 二进制
latin2_croatian_ci 克罗地亚语, 不区分大小写
latin2_czech_cs 捷克语, 区分大小写
latin2_general_ci 中欧 (多语言), 不区分大小写
latin2_hungarian_ci 匈牙利语, 不区分大小写
latin5 (ISO 8859-9 Turkish)
latin5_bin 土耳其语, 二进制
latin5_turkish_ci 土耳其语, 不区分大小写
latin7 (ISO 8859-13 Baltic)
latin7_bin 巴拉克语 (多语言), 二进制
latin7_estonian_cs 爱沙尼亚语, 区分大小写
latin7_general_ci 巴拉克语 (多语言), 不区分大小写
latin7_general_cs 巴拉克语 (多语言), 区分大小写
macce (Mac Central European)
macce_bin 中欧 (多语言), 二进制
macce_general_ci 中欧 (多语言), 不区分大小写
macroman (Mac West European)
macroman_bin 西欧 (多语言), 二进制
macroman_general_ci 西欧 (多语言), 不区分大小写
sjis (Shift-JIS Japanese)
sjis_bin 日语, 二进制
sjis_japanese_ci 日语, 不区分大小写
swe7 (7bit Swedish)
swe7_bin 瑞典语, 二进制
swe7_swedish_ci 瑞典语, 不区分大小写
tis620 (TIS620 Thai)
tis620_bin 泰语, 二进制
tis620_thai_ci 泰语, 不区分大小写
ucs2 (UCS-2 Unicode)
ucs2_bin Unicode (多语言), 二进制
ucs2_czech_ci 捷克语, 不区分大小写
ucs2_danish_ci 丹麦语, 不区分大小写
ucs2_estonian_ci 爱沙尼亚语, 不区分大小写
ucs2_general_ci Unicode (多语言), 不区分大小写
ucs2_icelandic_ci 冰岛语, 不区分大小写
ucs2_latvian_ci 拉脱维亚语, 不区分大小写
ucs2_lithuanian_ci 立陶宛语, 不区分大小写
ucs2_persian_ci 波斯语, 不区分大小写
ucs2_polish_ci 波兰语, 不区分大小写
ucs2_roman_ci 西欧, 不区分大小写
ucs2_romanian_ci 罗马尼亚语, 不区分大小写
ucs2_slovak_ci 斯洛伐克语, 不区分大小写
ucs2_slovenian_ci 斯洛文尼亚语, 不区分大小写
ucs2_spanish2_ci 传统西班牙语, 不区分大小写
ucs2_spanish_ci 西班牙语, 不区分大小写
ucs2_swedish_ci 瑞典语, 不区分大小写
ucs2_turkish_ci 土耳其语, 不区分大小写
ucs2_unicode_ci Unicode (多语言), 不区分大小写
ujis (EUC-JP Japanese)
ujis_bin 日语, 二进制
ujis_japanese_ci 日语, 不区分大小写
utf8 (UTF-8 Unicode)
utf8_bin Unicode (多语言), 二进制
utf8_czech_ci 捷克语, 不区分大小写
utf8_danish_ci 丹麦语, 不区分大小写
utf8_estonian_ci 爱沙尼亚语, 不区分大小写
utf8_general_ci Unicode (多语言), 不区分大小写
utf8_icelandic_ci 冰岛语, 不区分大小写
utf8_latvian_ci 拉脱维亚语, 不区分大小写
utf8_lithuanian_ci 立陶宛语, 不区分大小写
utf8_persian_ci 波斯语, 不区分大小写
utf8_polish_ci 波兰语, 不区分大小写
utf8_roman_ci 西欧, 不区分大小写
utf8_romanian_ci 罗马尼亚语, 不区分大小写
utf8_slovak_ci 斯洛伐克语, 不区分大小写
utf8_slovenian_ci 斯洛文尼亚语, 不区分大小写
utf8_spanish2_ci 传统西班牙语, 不区分大小写
utf8_spanish_ci 西班牙语, 不区分大小写
utf8_swedish_ci 瑞典语, 不区分大小写
utf8_turkish_ci 土耳其语, 不区分大小写
utf8_unicode_ci Unicode (多语言), 不区分大小写
作者：Lightning@小宝
发布时间：November 26, 2009
分类：MySQl学习笔记
mysql> pager grep sequence
PAGER SET TO 'grep sequence'
mysql> SHOW engine innodb STATUS\G SELECT sleep(60); SHOW engine innodb STATUS\G
Log sequence number 84 3836410803
1 row IN SET (0.06 sec)
1 row IN SET (1 min 0.00 sec)
Log sequence number 84 3838334638
1 row IN SET (0.05 sec)
mysql> SELECT (3838334638 - 3836410803) / 1024 / 1024 AS MB_per_min;
+------------+
| MB_per_min |
+------------+
| 1.83471203 |
+------------+
这样就可以得到每分钟的大小，乘以60，越等于64MB，所以innodb_log_file_size=64M
参考：http://www.mysqlperformanceblog.com/2008/11/21/how-to-calculate-a-good-innodb-log-file-size/
作者：Lightning@小宝
发布时间：November 18, 2009
分类：MySQl学习笔记
在目前的企业信息系统中，数据库还是最佳的数据存储方式，虽然已经有很多的书籍在指导我们进行数据库设计，但应该那种方式是设计数据库的表结构的最好方法、设计时应遵从什么样的原则、四个范式如何能够用一种方式达到顺畅的应用等是我一直在思考和总结的问题，下文是我针对这几个问题根据自己的设计经历准备总结的一篇文章的提纲，欢迎大家一块进行探讨，集思广益。其中提到了领域建模的概念，但未作详细解释，希望以后能够有时间我们针对这个命题进行深入探讨。
1)不应该针对整个系统进行数据库设计，而应该根据系统架构中的组件划分，针对每个组件所处理的业务进行组件单元的数据库设计；不同组件间所对应的数据库表之间的关联应尽可能减少，如果不同组件间的表需要外键关联也尽量不要创建外键关联，而只是记录关联表的一个主键，确保组件对应的表之间的独立性，为系统或表结构的重构提供可能性。
2)采用领域模型驱动的方式和自顶向下的思路进行数据库设计，首先分析系统业务，根据职责定义对象。对象要符合封装的特性，确保与职责相关的数据项被定义在一个对象之内，这些数据项能够完整描述该职责，不会出现职责描述缺失。并且一个对象有且只有一项职责，如果一个对象要负责两个或两个以上的职责，应进行分拆。
3)根据建立的领域模型进行数据库表的映射，此时应参考数据库设计第二范式：一个表中的所有非关键字属性都依赖于整个关键字。关键字可以是一个属性，也可以是多个属性的集合，不论那种方式，都应确保关键字能够保证唯一性。在确定关键字时，应保证关键字不会参与业务且不会出现更新异常，这时，最优解决方案为采用一个自增数值型属性或一个随机字符串作为表的关键字。
4)由于第一点所述的领域模型驱动的方式设计数据库表结构，领域模型中的每一个对象只有一项职责，所以对象中的数据项不存在传递依赖，所以，这种思路的数据库表结构设计从一开始即满足第三范式：一个表应满足第二范式，且属性间不存在传递依赖。
5)同样，由于对象职责的单一性以及对象之间的关系反映的是业务逻辑之间的关系，所以在领域模型中的对象存在主对象和从对象之分，从对象是从1－N或N－N的角度进一步主对象的业务逻辑，所以从对象及对象关系映射为的表及表关联关系不存在删除和插入异常。
6)在映射后得出的数据库表结构中，应再根据第四范式进行进一步修改，确保不存在多值依赖。这时，应根据反向工程的思路反馈给领域模型。如果表结构中存在多值依赖，则证明领域模型中的对象具有至少两个以上的职责，应根据第一条进行设计修正。第四范式：一个表如果满足BCNF，不应存在多值依赖。
7)在经过分析后确认所有的表都满足二、三、四范式的情况下，表和表之间的关联尽量采用弱关联以便于对表字段和表结构的调整和重构。并且，我认为数据库中的表是用来持久化一个对象实例在特定时间及特定条件下的状态的，只是一个存储介质，所以，表和表之间也不应用强关联来表述业务（数据间的一致性），这一职责应由系统的逻辑层来保证，这种方式也确保了系统对于不正确数据（脏数据）的兼容性。当然，从整个系统的角度来说我们还是要尽最大努力确保系统不会产生脏数据，单从另一个角度来说，脏数据的产生在一定程度上也是不可避免的，我们也要保证系统对这种情况的容错性。这是一个折中的方案。
8)应针对所有表的主键和外键建立索引，有针对性的（针对一些大数据量和常用检索方式）建立组合属性的索引，提高检索效率。虽然建立索引会消耗部分系统资源，但比较起在检索时搜索整张表中的数据尤其时表中的数据量较大时所带来的性能影响，以及无索引时的排序操作所带来的性能影响，这种方式仍然是值得提倡的。
9)尽量少采用存储过程，目前已经有很多技术可以替代存储过程的功能如“对象/关系映射”等，将数据一致性的保证放在数据库中，无论对于版本控制、开发和部署、以及数据库的迁移都会带来很大的影响。但不可否认，存储过程具有性能上的优势，所以，当系统可使用的硬件不会得到提升而性能又是非常重要的质量属性时，可经过平衡考虑选用存储过程。
10)当处理表间的关联约束所付出的代价（常常是使用性上的代价）超过了保证不会出现修改、删除、更改异常所付出的代价，并且数据冗余也不是主要的问题时，表设计可以不符合四个范式。四个范式确保了不会出现异常，但也可能由此导致过于纯洁的设计，使得表结构难于使用，所以在设计时需要进行综合判断，但首先确保符合四个范式，然后再进行精化修正是刚刚进入数据库设计领域时可以采用的最好办法。
11)设计出的表要具有较好的使用性，主要体现在查询时是否需要关联多张表且还需使用复杂的SQL技巧。
12)设计出的表要尽可能减少数据冗余，确保数据的准确性，有效的控制冗余有助于提高数据库的性能。
作者：Lightning@小宝
发布时间：November 2, 2009
分类：MySQl学习笔记
1.如果客户端和服务器端的连接需要跨越并通过不可信任的网络，那么就需要使用SSH隧道来加密该连接的通信。
2.用set password语句来修改用户的密码，三个步骤 “先mysql -u root登陆数据库系统” 然后“mysql> update mysql.user set password=password('newpwd')” 最后执行“flush privileges”就可以了。
3.需要提防的攻击有，防偷听、篡改、回放、拒绝服务等，不涉及可用性和容错方面。对所有的连接、查询、其他操作使用基于ACL即访问控制列表的安全措施来完成。也有一些对SSL连接的支持。
4.除了root用户外的其他任何用户不允许访问mysql主数据库中的user表;加密后存放在user表中的加密后的用户密码一旦泄露，其他人可以随意用该用户名/密码相应的数据库;
5.用grant和revoke语句来进行用户访问控制的工作;
6.不使用明文密码，而是使用md5()和sha1()等单向的哈系函数来设置密码;
7.不选用字典中的字来做密码;
8.采用防火墙来去掉50%的外部危险，让数据库系统躲在防火墙后面工作，或放置在DMZ区域中;
9.从因特网上用nmap来扫描3306端口，也可用telnet server_host 3306的方法测试，不能允许从非信任网络中访问数据库服务器的3306号TCP端口，因此需要在防火墙或路由器上做设定;
10.为了防止被恶意传入非法参数，例如where ID=234，别人却输入where ID=234 OR 1=1导致全部显示，所以在web的表单中使用''或""来用字符串，在动态URL中加入%22代表双引号、%23代表井号、%27代表单引号;传递未检查过的值给mysql数据库是非常危险的;
11.在传递数据给mysql时检查一下大小;
12.应用程序需要连接到数据库应该使用一般的用户帐号，只开放少数必要的权限给该用户;
13.在各编程接口(C C++ PHP Perl Java JDBC等)中使用特定‘逃脱字符’函数;在因特网上使用mysql数据库时一定少用传输明文的数据，而用SSL和SSH的加密方式数据来传输;
14.学会使用tcpdump和strings工具来查看传输数据的安全性，例如tcpdump -l -i eth0 -w -src or dst port 3306 | strings.以普通用户来启动mysql数据库服务;
15.不使用到表的联结符号，选用的参数 ——skip-symbolic-links;
16.确信在mysql目录中只有启动数据库服务的用户才可以对文件有读和写的权限;
17.不许将process或super权限付给非管理用户，该mysqladmin processlist可以列举出当前执行的查询文本;super权限可用于切断客户端连接、改变服务器运行参数状态、控制拷贝复制数据库的服务器;
18.file权限不付给管理员以外的用户，防止出现load data '/etc/passwd'到表中再用select 显示出来的问题;
19.如果不相信DNS服务公司的服务，可以在主机名称允许表中只设置IP数字地址;
20.使用max_user_connections变量来使mysqld服务进程，对一个指定帐户限定连接数;
21.grant语句也支持资源控制选项;
22.启动mysqld服务进程的安全选项开关，——local-infile=0或1 若是0则客户端程序就无法使用local load data了，赋权的一个例子grant insert(user) on mysql.user to 'user_name'@'host_name'; 若使用——skip-grant-tables系统将对任何用户的访问不做任何访问控制，但可以用mysqladmin flush-privileges或mysqladmin reload来开启访问控制;默认情况是show databases语句对所有用户开放，可以用——skip-show-databases来关闭掉。
23.碰到Error 1045(28000) Access Denied for user 'root'@'localhost' (Using password：NO)错误时，你需要重新设置密码，具体方法是：先用——skip-grant-tables参数启动mysqld，然后执行 mysql -u root mysql，mysql>update user set password=password('newpassword') where user='root';mysql>Flush privileges;，最后重新启动mysql就可以了。
来源:IT专家网论坛
作者：Lightning@小宝
发布时间：October 24, 2009
分类：MySQl学习笔记
DBA要创建额外价值以获取更多的回报, 前提是要有丰富的技术积累, 然后努力去运用积累的技术去满足公司或客户的需求. 每个人对于技术积累的理解有所不同, 在这里说一下个人的看法, 个人注重以下四个方面的技术积累.
基础知识积累, 这一点大伙都没有疑问, 并且谁都很重视, 例如努力阅读技术资料, 积极与人讨论, 上ITPub阅读技术贴子, 参加技术培训等, 都是基础知识积累的有效手段. 有个一年半载的时间, 可以将基础知识学得比较扎实, 可以将DBA的常规工作做得非常好了.
实践经验积累, 这部份是经过亲自实践的那部份基础知识的集合, 加上在运用基础知识的过程中措索出来的有效解决问题的方法或思维模式的结合体. 这部份其实并没有超出基础知识的范畴, 经常会发现, 一个问题得到解决的手段是靠很基础的知识点, 单独拎出来的话, 绝对是考100分的那种, 但往往解决问题的人不是你. 因此我也认为只完成了基础知识积累是不够的, 还必须经过一层有效的转换, 能够确实去解决问题.
用户需求积累, 学习技术后最大的乐趣是去帮助别人, 一种是去教导别人, 还有一种是去解决用户的需求. 既然解决需求是技术的最终目的, 那么我们就要去积累用户的需求, 根据用户的需求深化技术领域, 学以致用比较重要. 对于这一点体会比较深刻的是文本导出工具, 居然前前后后历时三年, 还有新的用户需求出来, 不是因为什么OCI编程的基础知识积累驱动了我, 而是用户需求驱动我去持续维护.
工具脚本积累, 要轻构地发挥DBA价值, 就要有称手的利器, 脚本和工具就是称手的利器. 在DBA的领域里, 虽然有很多前辈们写的现成脚本或工具, 但出自国内的DBA之手的工具还很少, 国内的DBA还是需要关注这一点, 这方面和国外DBA的差距不是一点的大, 虽然我们的基础知识及实践经验比他们丰富, 对比工作过的一个外资公司和一个国内公司, 在工具方面的差别有点让我震憾. SQLULDR, WebChart及oramon为我的DBA工作提供了很大的方便, 让我可以比其他DBA更快更好地了解所要管理的系统的运行特点.
以上是个人对自身技术积累的一点总结, 希望对大家有点帮助. anysql.net
- 页码:
- 1
- 2
- 3
- »
