我的JAVAWEB工程SQL语句在MYSQL中可以正确执行，但是在TOMCAT里却报错，求助解答~~~_百度知道
我的JAVAWEB工程SQL语句在MYSQL中可以正确执行，但是在TOMCAT里却报错，求助解答~~~
我有更好的答案
我分析可能的原因是：程序中连接数据库失败；sql中的参数有误；程序中的sql被做了转义。具体问题及解决，还是需要你贴出错误信息。从错误提示上看，是sql语法错误。建议你把程序中生成的sql打印一下看看。
这是我的方法，传进来的OrderLIst中读取的所有都是正确的~~
sql的拼接方式有误，表名不能用参数的形式传递。建议表名的判断写在 String sql=...... 这个语句前，也就是说，在写这个语句时，就把表名判断出来，并写在sql中。
采纳率：85%
　　具体报什么错？贴出来啊，把SQL语句也贴出来
你的SQL语句错了。表名不能作为参数，你只能写好多个SQL语句，根据你的参数选择SQL语句，表名是不能做参数的。或者你另外写法是可以的。用StringBff。
为您推荐：
其他类似问题
sql语句的相关知识
换一换
回答问题，赢新手礼包
个人、企业类
违法有害信息,请在下方选择后提交
色情、暴力
我们会通过消息、邮箱等方式尽快将举报结果通知您。一些自己的理解以及从别人那里学习的经验
JavaWeb（4）简单的SQL语句
SQL语句分类数据定义语言：简称DDL(Data Definition Language) ，DDL用于对数据库中的对象进行新增、修改、删除。其中DDL中有三个关键字分别是：CREATE新增
DROP删除创建数据库sql公式CREATE DATABASE 数据库名 [CHARACTER SET utf8]创建表sql公式CREATE TABLE 表名(
列1 类型 [约束],
列2 类型 [约束],
…);修改表结构，为表新增一列ALTER TABLE 表名 ADD 列名 列的数据类型;修改表结构，修改列ALTER TABLE 表名 CHANGE 旧列名 新列名 新列的数据类型;修改表结构，删除列ALTER TABLE 表名 DROP 要删除的列名;删除数据库DROP DATABASE 数据库名删除表DROPTABLE 表名数据操作语言：简称DML(Data Manipulation Language)，DML用于对数据库中表中的数据进行新增、修改、删除。其中DML中有三个关键字分别是：插入 INSERT
修改UPDATE
删除DELETE向表中插入数据的公式NSERT INTO 表名 VALUES(数值1,数值2,数值3,,…)，（此时values后括号中的数值要和表结构中的数值的个数，类型，顺序一一对应）。修改表中数据的公式UPDATE
表名 SET 列1=数据1,列2=数据2,... [WHERE id = 1]，（为了不把表中的数据全部修改成一样的数据，我们要加上条件语句where）。删除表中数据的公式DELETE FROM 表名 [WHERE id = 1]，（为了不把表中的数据全部删除，我们要加上条件语句where，FROM关键字不能省略）数据查询语言：简称DQL(Data Query Language) ，DQL用户对表中的数据进行查询。DQL只有一个关键字：SELECT。简单查询数据表公式：SELECT * FROM 表名数据控制语言：简称DCL(Data Control Language)，DCL对用户或角色赋予权限以及收回权限。其中DCL有两个关键字：赋予权限 GRANT
收回权限 REVOKE。将查询表的权限赋予DAHUANG用户：GRANT SELECT ON *.* TO DAHUANG;将查询表的权限从DAHUANG用户收回REVOKE SELECT ON *.* FROM DAHUANG;未立即透彻（有待完善）group by分组
order by排序
like模糊查询SQL语句语法- SQL语句可以单行或多行书写，以分号结尾。- 可使用空格和缩进来增强语句的可读性。- MySQL数据库的SQL语句不区分大小写，建议使用大写，例如：SELECT * FROM user。- 可以使用/**/的方式完成注释。扩展知识（操作数据库）查看所有数据库的sql语句：SHOW DATABASES;查看数据库创建时信息的sql语句：SHOW CREATE DATABASE 数据库名;
没有更多推荐了，
加入CSDN，享受更精准的内容推荐，与500万程序员共同成长！Java开发者写SQL时常犯的10个错误 - ImportNew
我十分惊讶的发现，我最近的一篇文章——《》——最近在和上非常的受欢迎。（这篇博客）的流行程度说明了几件事：
SQL在专业的Java开发中多么重要。
基本的SQL知识被忘掉（的情况）普遍存在。
通过，你就能了解像 或这样的以SQL为中心的库正好反应了市场的需要。 令人惊喜的是有用户提到了我博客上贴的一篇“”，SLICK是Scala中的一个不以SQL为中心的数据库访问库，像LINQ（还有LINQ-to-SQL），它侧重语言整合，而不是SQL语句的产生。
无论如何，我之前仓促列出的常见错误还没列完。因此我为你另外准备了10个没那么常见的，但Java开发者在写SQL语句时同样爱犯的错误。
1、不用PreparedStatements
有意思的是，在JDBC出现了许多年后的今天，这个错误依然出现在博客、论坛和邮件列表中，即便要记住和理解它是一件很简单的事。开发者不使用PreparedStatements的原因可能有如下几个：
他们对PreparedStatements不了解
他们认为使用PreparedStatements太慢了
他们认为写PreparedStatements太费力
来吧，我们来破除上面的谣言。96%的案例中，用PreparedStatement比静态声明语句更好。为什么呢？就是下面这些简单的原因：
使用内联绑定值（inlining bind values）可以从源头上避免糟糕的语句引起语法错误。
使用内联绑定值可以避免糟糕的语句引起的SQL注入漏洞。
当插入更多“复杂的”数据类型（比如时间戳、二进制数据等等）时，可以避免边缘现象（edge-cases）。
你若保持PreparedStatements的连接开启状态而不马上关闭，只要重新绑定新值就可以进行复用。
你可以在更多复杂的数据库里使用——自适应游标共享（Oracle的说法）。这可以帮你在每次新设定绑定值时阻止SQL语句硬解析。
（译者注：硬解析的弊端。硬解析即整个SQL语句的执行需要完完全全的解析，生成执行计划。而硬解析，生成执行计划需要耗用CPU资源，以及SGA资源。在此不得不提的是对库缓存中 闩的使用。闩是锁的细化，可以理解为是一种轻量级的串行化设备。当进程申请到闩后，则这些闩用于保护共享内存的数在同一时刻不会被两个以上的进程修改。在 硬解析时，需要申请闩的使用，而闩的数量在有限的情况下需要等待。大量的闩的使用由此造成需要使用闩的进程排队越频繁，性能则逾低下）
某些特殊情况下你需要对值进行内联绑定，这是为了给基于成本的性能优化器提示该查询将要涉及的数据集。典型的情况是用“常量”判断：
DELETED = 1
STATUS = 42
而不应该用一个“变量”判断：
FIRST_NAME LIKE “Jon%”
AMOUNT & 19.95
要注意的是，现代数据库已经实现了绑定数据窥探（bind-variable peeking）。因此，默认情况下，你也可以为你所有的查询参数使用绑定值。在你写嵌入的JPQL或嵌入的SQL时，用或者这类高层次的API可以很容易也很清晰的帮你生成PreparedStatements语句并绑定值。
更多的背景资料：
绑定数据窥探（bind-variable peeking）的附加说明：这个主题有一篇有趣的文章，。
游标分享。。
解决方案：
默认情况下，总是使用PreparedStatements来代替静态声明语句，而永远不要在你的SQL语句嵌入内联绑定值。
2、返回太多列
这个错误发生的非常频繁，它不光会影响你的数据库执行计划，也会对你的Java应用造成不好的影响。让我们先看看对后者的影响：
对Java程序的不良影响:
如 果你为了满足不同DAO层之间的数据复用而select *或者默认的50个列，这样将会有大量的数据从数据库读入到JDBC结果集中，即使你不从结果集读取数据，它也被传递到了线路上并被JDBC驱动器加载到 了内存中。如果你知道你只需要2-3列数据的话，这就造成了严重的IO和内存的浪费。
这个（问题的严重性）都是显而易见的，要小心……
对数据库执行计划的不良影响：
这 些影响事实上可能比对Java应用的影响还要严重。当复杂的数据库要针对你的查询请求计算出最佳执行计划时，它会进行大量的SQL转换（SQL transformation ）。还好，请求中的一部分可以被略去，因为它们对SQL连映射或过滤条件起不了什么作用。我最近写了一篇博客来讲述这个问题：。
现在，给你展示一个错误的例子。想一想有两个视图的复杂查询：
customer_view c
order_view o
c.cust_id = o.cust_id
每个关联了上述关联表引用的视图也可能再次关联其他表的数据，像 CUSTOMER_ADDRESS、ORDER_HISTORY、ORDER_SETTLEMENT等等。进行select * 映射时，你的数据库除了把所有连接表都加载进来以外别无选择，实际上，你唯一感兴趣的数据可能只有这些：
SELECT c.first_name, c.last_name, o.amount
customer_view c
order_view o
c.cust_id = o.cust_id
一个好的数据库会在转换你的SQL语句时自动移除那些不需要的连接，这样数据库就只需要较少的IO和内存消耗。
解决方案：
永远不要用select *（这样的查询）。也不要在执行不同请求时复用相同的映射。尽量尝试减少映射到你所真正需要的数据。
需要注意的是，想在对象-关系映射（ORMs）上达成这个目标有些难。
3、把JOIN当做了SELECT的子句
对于性能或SQL语句的正确性来说，这不算错。但是不管如何，SQL开发者应该意识到JOIN子句不是SELECT语句的一部分。 定义了表引用：
6.3 &table reference&
&table reference& ::=
&table name& [ [ AS ] &correlation name&
[ &left paren& &derived column list& &right paren& ] ]
| &derived table& [ AS ] &correlation name&
[ &left paren& &derived column list& &right paren& ]
| &joined table&
7.4 &from clause&
&from clause& ::=
FROM &table reference& [ { &comma& &table reference& }... ]
7.5 &joined table&
&joined table& ::=
&cross join&
| &qualified join&
| &left paren& &joined table& &right paren&
&cross join& ::=
&table reference& CROSS JOIN &table reference&
&qualified join& ::=
&table reference& [ NATURAL ] [ &join type& ] JOIN
&table reference& [ &join specification& ]
关联数据库是以表为中心的。许多的操作的某方面都是执行在物理表、连接表或派生表上的。为了有效的写出SQL语句，理解SELECT … FROM子句是以“，”分割表引用是非常重要的。
基于表引用（table references）的复杂性，一些数据库也接受其它类型的复杂的表引用（table references），像INSERT、UPDATE、DELETE、MERGE。看看，里面解释了如何创建可更新的视图。
解决方案：
一定要考虑到，一般说来，FROM子句也是一个表引用（table references）。如果你写了JOIN子句，要考虑这个JOIN子句是这个复杂的表引用的一部分：
SELECT c.first_name, c.last_name, o.amount
FROMcustomer_view c
JOIN order_view o
ON c.cust_id = o.cust_id
4、使用ANSI 92标准之前连接语法
我 们已经说清了表引用是怎么工作的（看上一节），因此我们应该达成共识，不论花费什么代价，都应该避免使用ANSI 92标准之前的语法。就执行计划而言，使用JOIN…ON子句或者WHERE子句来作连接谓语没有什么不同。但从可读性和可维护性的角度看，在过滤条 件判断和连接判断中用WHERE子句会陷入不可自拔的泥沼，看看这个简单的例子：
SELECT c.first_name, c.last_name, o.amount
customer_view c,
order_view o
o.amount & 100
c.cust_id = o.cust_id
c.language = 'en'
你能找到join谓词么？如果我们加入数十张表呢？当你使用外连接专有语法的时候会变得更糟，就像里讲的一样。
解决方案：
一定要用ANSI 92标准的JOIN语句。不要把JOIN谓词放到WHERE子句中。用ANSI 92标准之前的JOIN语法没有半点好处。
5、使用LIKE判定时忘了ESCAPE
指出like判定应该如下：
8.5 &like predicate&
&like predicate& ::=
&match value& [ NOT ] LIKE &pattern&
[ ESCAPE &escape character& ]
当允许用户对你的SQL查询进行参数输入时，就应该使用ESCAPE关键字。尽管数据中含有百分号（%）的情况很罕见，但下划线（_）还是很常见的：
t.x LIKE 'some!_prefix%' ESCAPE '!'
解决方案：
使用LIKE判定时，也要使用合适的ESCAPE
6、认为 NOT (A IN (X, Y)) 和 IN (X, Y) 的布尔值相反
对于NULLs，这是一个举足轻重的细节！让我们看看 A IN (X, Y) 真正意思吧：
A IN (X, Y)
is the same as
A = ANY (X, Y)
is the same as
A = X OR A = Y
When at the same time, NOT (A IN (X, Y)) really means:
同样的，NOT (A IN (X, Y))的真正意思：
NOT (A IN (X, Y))
is the same as
A NOT IN (X, Y)
is the same as
A != ANY (X, Y)
is the same as
A != X AND A != Y
看起来和之前说的布尔值相反一样？其实不是。如果X或Y中任何一个为NULL，NOT IN 条件产生的结果将是UNKNOWN，但是IN条件可能依然会返回一个布尔值。
或者换种说话，当 A IN (X, Y) 结果为TRUE或FALSE时，NOT(A IN (X, Y)) 结果为依然UNKNOWN而不是FALSE或TRUE。注意了，如果IN条件的右边是一个子查询，结果依旧。
不信？你自己看 去。它说了如下查询给不出结果：
1 IN (NULL)
WHERE NOT(1 IN (NULL))
更多细节可以参考,上面写了在同区域内不兼容的一些SQL方言。
解决方案：
当涉及到可为NULL的列时，注意NOT IN条件。
7、认为NOT (A IS NULL)和A IS NOT NULL是一样的
没错，我们记得处理NULL值的时候，SQL实现了三值逻辑。这就是我们能用NULL条件来检测NULL值的原因。对么？没错。
但在NULL条件容易遗漏的情况下。要意识到下面这两个条件仅仅在行值表达式（row value expressions）为1的时候才相等：
NOT (A IS NULL)
is not the same as A IS NOT NULL
如果A是一个大于1的行值表达式（row value expressions），正确的表将按照如下方式转换：
如果A的所有值为NUll，A IS NULL为TRUE
如果A的所有值为NUll，NOT(A IS NULL) 为FALSE
如果A的所有值都不是NUll，A IS NOT NULL 为TRUE
如果A的所有值都不是NUll，NOT(A IS NOT NULL)
在我的可以了解到更多细节。
解决方案：
当使用行值表达式（row value expressions）时，要注意NULL条件不一定能达到预期的效果。
8、不用行值表达式
行值表达式是SQL一个很棒的特性。SQL是一个以表格为中心的语言，表格又是以行为中心。通过创建能在同等级或行类型进行比较的点对点行模型，行值表达式让你能更容易的描述复杂的判定条件。一个简单的例子是，同时请求客户的姓名
SELECT c.address
customer c,
WHERE (c.first_name, c.last_name) = (?, ?)
可以看出，就将每行的谓词左边和与之对应的右边比较这个语法而言，行值表达式的语法更加简洁。特别是在有许多独立条件通过AND连接的时候就特别有效。行值表达式允许你将相互联系的条件放在一起。对于有外键的JOIN表达式来说，它更有用：
SELECT c.first_name, c.last_name, a.street
customer c
(c.id, c.tenant_id) = (a.id, a.tenant_id)
不幸的是，并不是所有数据库都支持行值表达式。但SQL标准已经在对行值表达式进行了定义，如果你使用他们，像Oracle或Postgres这些的复杂数据库可以使用它们计算出更好的执行计划。在这个页面上有解析。
解决方案：
不管干什么都可以使用行值表达式。它们会让你的SQL语句更加简洁高效。
9、不定义足够的限制条件（constraints）
我又要再次引用 和
了。对你的元数据使用限制条件不能更赞了。首先，限制条件可以帮你防止数据质变，光这一点就很有用。但对我来说更重要的是，限制条件可以帮助数据库进行SQL语句转换，数据库可以决定。
哪些值是等价的
哪些子句是冗余的
哪些子句是无效的（例如，会返回空值的语句）
有些开发者可能认为限制条件会导致（数据库）变慢。但相反，除非你插入大量的数据，对于大型操作是你可以禁用限制条件，或用一个无限制条件的临时“载入表”，线下再把数据转移到真实的表中。
解决方案：
尽可能定义足够多的限制条件（constraints）。它们将帮你更好的执行数据库请求。
10、认为50ms是一个快的查询速度
的炒作依然在继续，许多公司认为它们像Twitter或Facebook一样需要更快、扩展性更好的解决方案，想脱离ACID和关系模型横向扩展。有些可能会成功（比如Twitter或Facebook），而其他的也许会走入误区：
看这篇文章：。
对于那些仍被迫（或坚持）使用关系型数据 库的公司，请不要自欺欺人的认为：“现在的关系型数据库很慢，其实它们是被天花乱坠的宣传弄快的”。实际上，它们真的很快，解析20Kb查询文档，计算 2000行执行计划，如此庞大的执行，所需时间小于1ms，如果你和数据管理员（DBA）继续优化调整数据库，就能得到最大限度的运行。
它们会变慢的原因有两种：一是你的应用滥用；二是ORM无法针对你复杂的查询逻辑产生快的SQL语句。遇到这种情况，你就要考虑选择像 、 或这样的更贴近SQL核心，能更好的控制你的SQL语句的API。
因此，不要认为查询速度50ms是很快或者可以接受的。完全不是！如果你程序运行时间是这样的，请检查你的执行计划。这种潜在危险可能会在你执行更复杂的上下文或数据中爆发。
SQL很有趣，同时在各种各样的方面也很微妙。正如我的关于的博客所展示的。跋山涉水也要掌握SQL是一件值得做的事。数据是你最有价值的资产。带着尊敬的心态对待你的数据才能写出更好的SQL语句。
原文链接：
- 译文链接： [ 转载请保留原文出处、译者和译文链接。]
关于作者：
（新浪微博：）
讨论快慢离开具体情况（insert/delete和get）都是刷流氓。看楼主的意思，应该是get的情...
tony.chenjy
关于ImportNew
ImportNew 专注于 Java 技术分享。于日 11:11正式上线。是的，这是一个很特别的时刻 :)
ImportNew 由两个 Java 关键字 import 和 new 组成，意指：Java 开发者学习新知识的网站。 import 可认为是学习和吸收， new 则可认为是新知识、新技术圈子和新朋友……
新浪微博：
推荐微信号
反馈建议：ImportNew.
广告与商务合作QQ：
– 好的话题、有启发的回复、值得信赖的圈子
– 写了文章？看干货？去头条！
– 为IT单身男女服务的征婚传播平台
– 优秀的工具资源导航
– 活跃 & 专业的翻译小组
– 国内外的精选博客文章
– UI,网页，交互和用户体验
– JavaScript, HTML5, CSS
– 专注Android技术分享
– 专注iOS技术分享
– 专注Java技术分享
– 专注Python技术分享
& 2018 ImportNew您现在的位置： &
sql:query使用语法说明
Java Web标签应用开发_sql:query使用语法说明
&sql:query&标签用于查询数据库中的数据，这就相当于执行select查询SQL语句。使用&sql:query&标签的语法如下：语法1：不带body&sql:query sql=&SQL查询语句&var=&变量名& [scope=&{page|request|session|application}&][dataSource=&数据源&] [maxRows=&返回的记录集最大行数&][startRow=&返回的记录集的起始位置&]/&语法2：带有指定查询参数的body&sql:query sql=& SQL查询语句&var=&变量名& [scope=&{page|request|session|appl..
&&&主编推荐
&&&最新图书
&&&最新视频
&&&热门试卷
& & & & & & & &Javaweb+SQLserver开发心得
通过开发本次项目，让我对javaWeb以及SQLserver有了更深入的了解。在本次项目中，我最主要负责的是数据库以及文档编辑的方面。以前我们的数据库学习一直停留在MySQL，并没有过多的学习，这个学期我们对SQLserver进行了学习以及实操，即方便了我们对数据库的操作，也学会了以前不知道的数据库的知识。
SQL是为结构化查询语言。SQL语言的主要功能就是同各种数据库建立联系，进行沟通。按照ANSI(美国国家标准协会）的规定，SQL被作为关系型数据库管理系统的标准语言。SQL语句可以用来执行各种各样的操作，例如更新数据库中的数据，从数据库中提取数据等。绝大多数流行的关系型数据库管理系统，如Oracle,Sybase,Microsoft SQL
Server,Access等都采用了SQL语言标准。虽然很多数据库都对SQL语句进行了再开发和扩展，但是包括Select,Insert,Update,Delete,Create，以及Drop在内的标准的SQL命令仍然可以被用来完成几乎所有的数据库操作。SQL Server
是一个关系数据库管理系统。当然，javaweb是与数据库相辅相成的存在关系。通过本次的项目，对javaweb与SQLserver连接的方法有了进一步的了解以及学习。Javaweb以及SQLserver是为后台做铺垫的。只要需要数据交流，这两项是必不可少的。
已投稿到：
以上网友发言只代表其个人观点，不代表新浪网的观点或立场。}