绝无经由的MySQL基础操纵(把持台)
表里面的记录数量越多，这个操作的代价就越高。如果作为搜索条件的列上已经创建了索引，MySQL无需扫描任何记录即可迅速得到目标记录所在的位置。1.进进MySQL服务器:>mysql-hlocalhost(大概127.0.0.1)-uroot(填写用户名)-p(回车然后输出暗码)。
2.利用show语句检察以后服务器上有哪些数据库。
mysql>showdatabases;
3.利用某个已存在数据库:
mysql>usedatabase_name;
4.创立数据库:
mysql>createdatabasedatabase_name;
5.显现某个数据库中的表：
mysql>showtables;
6.创立表：
mysql>createtabletable_name(c1varchar(20),c2int(3),......);
7.显现表book中的字段：
mysql>describebook;
8.向表中一次增加多笔记录:
mysql>insertintobookvalues(value_1,value_2.....),.....(value_n,value_n+1);
更具体的操纵参看MySQL参考手册关于这个理由我把它放在最后一位。在很多业界专家中有一个相当一致的观点：MySQL不能很好的扩展。关于这点可能有很大的分歧，争论的焦点主要集中于水平可扩展性和垂直可扩展性上。MySQL则更倾向于垂直可扩展性。 比如，MicrosoftSQLServer2008的某一个版本可以满足现在的这个业务的需要，而且价格还比Oracle11g要便宜，那么这一产品就是适合的。 一直以来个人感觉SQLServer的优化器要比Oracle的聪明。SQL2005的更是比2k聪明了不少。（有次作试验发现有的语句在200万级时还比50万级的相同语句要快show_text的一些提示没有找到解释。一直在奇怪。） 现在是在考虑:如果写到服务器端,我一下搞他个10个存储过程导过去,那久之服务器不就成垃圾箱了吗?即便优化了我的中间层. 分区表效率问题肯定是大家关心的问题。在我的试验中，如果按照分区字段进行的查询（过滤）效率会高于未分区表的相同语句。但是如果按照非分区字段进行查询，效率会低于未分区表的相同语句。 在select语句中可以使用groupby子句将行划分成较小的组，然后，使用聚组函数返回每一个组的汇总信息，另外，可以使用having子句限制返回的结果集。 作了些试验，发现使用CLR的存储过程或函数在达到一定的阀值的时候，系统性能会呈指数级下滑！这是非常危险的！只使用几个可能没有问题，当一旦大规模使用会造成严重的系统性能问题！ 个人感觉没有case直观。而且默认的第三字段（还可能更多）作为groupby字段很容易造成新手的错误。
页:
[1]