❶ mysql优化一般需要做哪些其他数据库优化也行（sql）

1.硬件层次的优化
高频CPU，内存要大，磁盘转速要快，网络带宽要大。要硬件方面优化，花钱升级硬件吧。
2.软件层次的优化
我大概写一些吧，想到哪些写哪些，希望对你有用。
（1）优化安装mysql
一句话，只保留需要的、必须的，其他的统统丢掉。（这句话只适用于源码编译安装的情况，如果不是，请跳过）比如，字符集。如果安装全部字符集，大概有50多种吧...记不清了，大概有这么多，但是过多的字符集影响性能（虽然影响的不多，mysql查询机制中有一步是字符集检查）。源码编译安装的话可以大量减少字符集，只保留必须的和自己需要的那些。我维护的一个mysql服务器中的Mysql只有15个字符集。
还有就是配置文件、数据目录、系统目录不要放一块。俗话说的好，鸡蛋不要放在一个篮子里，不要在一颗树上吊死...当然，这对性能没有影响，考虑的是安全性。不是生产环境的，请无视这一条。
（2）内存分配优化。
在mysql中的配置文件中可以自定义多种缓存，适当的配给值可以提高mysql的整体性能。
比较重要的：
innodb_buffer_pool_size 这个值应该分配总内存的40-80%，总之 这个值越高越好。如果不是专属mysql服务器，那分配40%也很够用了。
query_cache_size 这个值分配灵活性也比较大，从几MB~几百MB。它缓存查询的结果集。查询不是能频繁、查询数据不是很大量的情况，分配个几MB就够了，杀鸡焉用牛刀啊，用内存的地方实在是多。
join_buffer_size，sort_buffer_size 一般设1MB，2MB就十分够用了。这俩值千万不要设置的太大，因为这俩缓存是分配给每个连接线程的，过多的连接线程可能导致内存不够用。
tmp_table_size 同样不是越大越好，分配10MB差不多够用。以后有需要可以适当多分配点。临时表缓存用于存放查询时产生的临时表，如果数据量大而tmp_table_size不够用那么Mysql会将临时表存到磁盘上导致性能下降。个人经验，当你觉得tmp_table_size不够用的时候，不要随便去增加这个值，而是检查自己的SQL语句是否还可以优化。
（3）复制与读写分离
内容太多...这个不好写啊。总之读写分离的目标是，安全、稳定、高效。访问量少、只有一台电脑的请无视这一段...

mysql的优化知识全部写出来能写出一本砖头厚的书，随便写了点自己知道的，能想到的。想了解更多，去看书吧。

我勒个去.....才看到题目后面的(sql)....吐一大口鲜血....你问的是sql优化？？？
再写点个人经验吧：
1.查询时，能不用* 就不用，尽量写全字段名。
2.索引不是越多越好，每个表控制在6个索引以内。范围where条件的情况下，索引不起作用，比如where value<100
3.大部分情况连接效率远大于子查询，但是有例外。当你对连接查询的效率都感到不能接受的时候可以试试用子查询，虽然大部分情况下你会更失望，但总有碰到惊喜的时候不是么...
4.多用explain 和 profile分析查询语句
5.有时候可以1条大的SQL可以分成几个小SQL顺序执行，分了吧，速度会快很多。
6.每隔一段时间用alter table table_name engine=innodb;优化表
7.连接时注意:小表 jion 大表的原则
8.学会用explain 和 profile判断是什么原因使你的SQL慢。
9.查看慢查询日志，找出执行时间长的SQL试着优化去吧~~

以上。

❷ 在数据库 如何实现多级树啊 表结构要怎么设置 比较好

无限级分类，很简单。你可以下载动易的ACCESS数据库，查看相应的表结构就知道是怎么设计的了。

而且，它这个表设计的很巧妙，压根就不需要递归循环，就能以树形的结构列出所有的类别。仅仅需要order by rootid,orderid就可以了。

记得以前是用ASP开发的时候接触到无限分类的，现在做PHP，.NET开发，都可以用它的那套机制。很好。

❸ 数据库查询有哪些优化方面

1 SQL查询语句的重写，对于一个查询可以用多种查询语句实现，但不同查询语句的数据库执行计划是不同的，一旦不能够使用索引或造成较大的内存占用会导致性能下降，因此需要对查询语句进行重写优化，最典型的例子就是not in语句使用外连接方式实现来进行优化
2 创建合理的索引结构，根据查询语句的中查询条件，在关系表上建立相应的索引，如B+树索引和hash索引
3 修改程序业务逻辑，有些功能如果使用SQL语句实现，不但SQL语句复杂，还将导致数据库的负担增加，因此可以将有些数据操作的业务逻辑放到应用层进行实现，就是通过java编程实现
4 修改数据库服务器相关参数，优化服务器性能

❹ 怎样用数据库做成一个树结构

就是表需要有一个主键，比如 ID
然后还有一个字段，叫 父编号， 比如 PID
再加上其他的字段，剩下的就是写 SQL 的事情了。

例如下面这个表，就是一个可以做树状的。
CREATE TABLE test_tree (
test_id INT,
pid INT,
test_val VARCHAR(10),
PRIMARY KEY (test_id)
);

❺ 树形结构数据的查询怎么优化

// 如果你指消息对话框，可以如下方法 QMessageBox msgBox; msgBox.setText("The document has been modified."); msgBox.exec();// 如果你指QDialog，那么你只能在QDialog上面绘制你的界面，然后进行文字显示QDialog *dlg = new QDialog();QLab...

❻ 数据库语法树问题

左边优化前，右边优化后

❼ 请问sql数据库优化具体是指的哪些方面呢有没有什么工具软件呢

1、数据库逻辑设计的规范化 数据库逻辑设计的规范化就是我们一般所说的范式，我们可以这样来简单理解范式：第1规范：没有重复的组或多值的列，这是数据库设计的最低要求。第2规范: 每个非关键字段必须依赖于主关键字，不能依赖于一个组合式主关键字的某些组成部分。消除部分依赖，大部分情况下，数据库设计都应该达到第二范式。第3规范: 一个非关键字段不能依赖于另一个非关键字段。消除传递依赖，达到第三范式应该是系统中大部分表的要求，除非一些特殊作用的表。更高的范式要求这里就不再作介绍了，个人认为，如果全部达到第二范式，大部分达到第三范式，系统会产生较少的列和较多的表，因而减少了数据冗余，也利于性能的提高。2、合理的冗余完全按照规范化设计的系统几乎是不可能的，除非系统特别的小，在规范化设计后，有计划地加入冗余是必要的。冗余可以是冗余数据库、冗余表或者冗余字段，不同粒度的冗余可以起到不同的作用。冗余可以是为了编程方便而增加，也可以是为了性能的提高而增加。从性能角度来说，冗余数据库可以分散数据库压力，冗余表可以分散数据量大的表的并发压力，也可以加快特殊查询的速度，冗余字段可以有效减少数据库表的连接，提高效率。3、主键的设计主键是必要的，SQL SERVER的主键同时是一个唯一索引，而且在实际应用中，我们往往选择最小的键组合作为主键，所以主键往往适合作为表的聚集索引。聚集索引对查询的影响是比较大的，这个在下面索引的叙述。在有多个键的表，主键的选择也比较重要，一般选择总的长度小的键，小的键的比较速度快，同时小的键可以使主键的B树结构的层次更少。主键的选择还要注意组合主键的字段次序，对于组合主键来说，不同的字段次序的主键的性能差别可能会很大，一般应该选择重复率低、单独或者组合查询可能性大的字段放在前面。4、外键的设计外键作为数据库对象，很多人认为麻烦而不用，实际上，外键在大部分情况下是很有用的，理由是：外键是最高效的一致性维护方法，数据库的一致性要求，依次可以用外键、CHECK约束、规则约束、触发器、客户端程序，一般认为，离数据越近的方法效率越高。谨慎使用级联删除和级联更新，级联删除和级联更新作为SQL SERVER 2000当年的新功能，在2005作 了保留，应该有其可用之处。我这里说的谨慎，是因为级联删除和级联更新有些突破了传统的关于外键的定义，功能有点太过强大，使用前必须确定自己已经把握好 其功能范围，否则，级联删除和级联更新可能让你的数据莫名其妙的被修改或者丢失。从性能看级联删除和级联更新是比其他方法更高效的方法。5、字段的设计字段是数据库最基本的单位，其设计对性能的影响是很大的。需要注意如下：A、数据类型尽量用数字型，数字型的比较比字符型的快很多。B、数据类型尽量小，这里的尽量小是指在满足可以预见的未来需求的前提下的。C、 尽量不要允许NULL，除非必要，可以用NOT NULL+DEFAULT代替。D、少用TEXT和IMAGE，二进制字段的读写是比较慢的，而且，读取的方法也不多，大部分情况下最好不用。E、自增字段要慎用，不利于数据迁移。6、数据库物理存储和环境的设计在设计阶段，可以对数据库的物理存储、操作系统环境、网络环境进行必要的设计，使得我们的系统在将来能适应比较多的用户并发和比较大的数据量。这里需要注意文件组的作用，适用文件组可以有效把I/O操作分散到不同的物理硬盘，提高并发能力。7、系统设计整个系统的设计特别是系统结构设计对性能是有很大影响的，对于一般的OLTP系统，可以选择C/S结构、三层的C/S结构等，不同的系统结构其性能的关键也有所不同。系统设计阶段应该归纳一些业务逻辑放在数据库编程实现，数据库编程包括数据库存储过程、触发器和函数。用数据库编程实现业务逻辑的好处是减少网络流量并可更充分利用数据库的预编译和缓存功能。8、索引的设计在设计阶段，可以根据功能和性能的需求进行初步的索引设计，这里需要根据预计的数据量和查询来设计索引，可能与将来实际使用的时候会有所区别。关于索引的选择，应改主意：A、根据数据量决定哪些表需要增加索引，数据量小的可以只有主键。B、根据使用频率决定哪些字段需要建立索引，选择经常作为连接条件、筛选条件、聚合查询、排序的字段作为索引的候选字段。C、把经常一起出现的字段组合在一起，组成组合索引，组合索引的字段顺序与主键一样，也需要把最常用的字段放在前面，把重复率低的字段放在前面。D、一个表不要加太多索引，因为索引影响插入和更新的速度。 具体有什么工具，我就不知道了