本文目录一览：
- 1、谁知道在Java中查询数据库后怎么把查询的值赋给一个变量啊 用ResultSet类的方法
- 2、如何在Java中获取环境变量的值
- 3、java程序操作sql报错 错误为： 并非所有变量都已绑定
- 4、jdbc查询数据库报：java.sql.SQLException: ORA-01006: 绑定变量不存在
- 5、Java程序员在写SQL时常犯的错误！
谁知道在Java中查询数据库后怎么把查询的值赋给一个变量啊 用ResultSet类的方法
理论上这样赋值
User_Money=rst.getString("Money");
但你要考虑一下你的数据库，如果username和Money不是一对一的关系，即一个名字对应三个Money，那么你sql语句得到的将是值
如果使用下面语句
if(rst.next()){
User_Money=rst.getString("Money");//将得到第一个值
}
如果使用下面语句
while(rst.next()){ //有下一个值存在，while循环将继续，那么User_Money连续被赋值
User_Money=rst.getString("Money");//将得到第三个值
}
如何在Java中获取环境变量的值
当程序中需要使用与操作系统相关的变量（例如：文件分隔符、换行符）时，Java提供了System类的静态方法getenv()和getProperty()用于返回系统相关的变量与属性，getenv方法返回的变量大多于系统相关，getProperty方法返回的变量大多与java程序有关。
系统属性和环境变量都是名称与值之间的映射。两种机制都能用来将用户定义的信息传递给 Java进程。环境变量产生更多的全局效应，因为它们不仅对Java子进程可见，而且对于定义它们的进程的所有子进程都是可见的。在不同的操作系统上，它们的语义有细微的差别，比如，不区分大小写。因此环境变量更可能有意料不到的副作用。程序中尽可能使用系统属性。环境变量应该在需要全局效应的时候使用，或者在外部系统接口要求使用环境变量时使用（比如 PATH）。
1、环境变量getenv() ：用于获取当前系统环境的字符串映射视图；测试代码及运行结果如下：
publicclass Test {
publicstaticvoid main(String[] args) {
MapString, String map = System.getenv();
for(IteratorString itr = map.keySet().iterator();itr.hasNext();){
String key = itr.next();
System.out.println(key + "=" + map.get(key));
}
}
}
USERPROFILE ：用户目录
USERDNSDOMAIN ：用户域
PATHEXT ：可执行后缀
JAVA_HOME ：Java安装目录
TEMP ：用户临时文件目录
SystemDrive ：系统盘符
ProgramFiles ：默认程序目录
USERDOMAIN ：帐户的域的名称
ALLUSERSPROFILE ：用户公共目录
SESSIONNAME ：Session名称
TMP ：临时目录
Path ：path环境变量
CLASSPATH ：classpath环境变量
PROCESSOR_ARCHITECTURE ：处理器体系结构
OS ：操作系统类型
PROCESSOR_LEVEL ：处理级别
COMPUTERNAME ：计算机名
Windir ：系统安装目录
SystemRoot ：系统启动目录
USERNAME ：用户名
ComSpec ：命令行解释器可执行程序的准确路径
APPDATA ：应用程序数据目录
2、系统属性getProperty() ：当前的系统属性。测试代码及运行结果如下：
java.version Java ：运行时环境版本
java.vendor Java ：运行时环境供应商
java.vendor.url ：Java供应商的 URL
java.home ：Java安装目录
java.vm.specification.version： Java虚拟机规范版本
java.vm.specification.vendor ：Java虚拟机规范供应商
java.vm.specification.name ：Java虚拟机规范名称
java.vm.version ：Java虚拟机实现版本
java.vm.vendor ：Java虚拟机实现供应商
java.vm.name ：Java虚拟机实现名称
java.specification.version：Java运行时环境规范版本
java.specification.vendor：Java运行时环境规范供应商
java.specification.name ：Java运行时环境规范名称
java.class.version ：Java类格式版本号
java.class.path ：Java类路径
java.library.path ：加载库时搜索的路径列表
java.io.tmpdir ：默认的临时文件路径
java.compiler ：要使用的 JIT编译器的名称
java.ext.dirs ：一个或多个扩展目录的路径
os.name ：操作系统的名称
os.arch ：操作系统的架构
os.version ：操作系统的版本
file.separator ：文件分隔符
path.separator ：路径分隔符
line.separator ：行分隔符
user.name ：用户的账户名称
user.home ：用户的主目录
user.dir：用户的当前工作目录
java程序操作sql报错 错误为： 并非所有变量都已绑定
您好，建议把sql语句在数据库中执行下，看能否正确执行。
我想大概是表里面所有的字段，你没有给全部赋值。
因为你insert into t_login 后面没有具体字段，那么就是全表的所有字段。
values后面给了三个字段。
jdbc查询数据库报：java.sql.SQLException: ORA-01006: 绑定变量不存在
胡乱猜测一下。
int i = 1;
if(um.getUuid() != null um.getUuid().trim().length() 0){
pstmt.setString(i, um.getUuid());
i++;
}
java中所有这种类似数组的东西，都应该是从0开始，而不是从1开始。
所以 int i = 0;
Java程序员在写SQL时常犯的错误！
Java程序员编程时需要混合面向对象思维和一般命令式编程的方法，能否完美的将两者结合起来完全得依靠编程人员的水准：
技能（任何人都能容易学会命令式编程）模式（有些人用“模式-模式”,举个例子,模式可以应用到任何地方，而且都可以归为某一类模式）心境（首先，要写个好的面向对象程序是比命令式程序难的多，你得花费一些功夫）
但当Java程序员写SQL语句时，一切都不一样了。SQL是说明性语言而非面向对象或是命令式编程语言。在SQL中要写个查询语句是很简单的。但在Java里类似的语句却不容易，因为程序员不仅要反复考虑编程范式，而且也要考虑算法的问题。
下面是Java程序员在写SQL时常犯的10个错误（没有特定的顺序）。
1、忘掉NULL
Java程序员写SQL时对NULL的误解可能是最大的错误。也许是因为（并非唯一理由）NULL也称作UNKNOWN。如果被称作 UNKNOWN，这还好理解些。另一个原因是，当你从数据库拿东西或是绑定变量时，JDBC将SQL NULL 和Java中的null对应了起来。这样导致了NULL = NULL（SQL）和null=null（Java）的误解。
对于NULL最大的误解是当NULL被用作行值表达式完整性约束条件时。另一个误解出现在对于NULL 在 NOT IN anti-joins的应用中。
解决方法：
好好的训练你自己。当你写SQL时要不停得想到NULL的用法：这个NULL完整性约束条件是正确的？NULL是否影响到结果？
2、在Java内存中处理数据
很少有Java开发者能将SQL理解的很好。偶尔使用的JOIN,还有古怪的UNION，好吧，但是对于窗口函数呢？还有对集合进行分组呢？许多 的Java开发者将SQL数据加载到内存中，将这些数据转换成某些相近的集合类型，然后再那些集合上面使用边界循环控制结构（至少在Java8的集合升级 以前）执行令人生厌的数学运算。
但是一些SQL数据库支持先进的（而且是SQL标准支持的）OLAP特性,这一特性表现更好而且写起来也更加方便。一个（并不怎么标准的）例子就 是Oracle超棒的MODEL分句。只让数据库来做处理然后只把结果带到Java内存中吧。因为毕竟所有非常聪明的家伙已经对这些昂贵的产品进行了优 化。因此实际上,通过将OLAP移到数据库，你将获得一下两项好处：
便利性。这比在Java中编写正确的SQL可能更加的容易。性能表现。数据库应该比你的算法处理起来更加快.而且更加重要的是,你不必再去传递数百万条记录了。
解决方法：
每次你使用Java实现一个以数据为中心的算法时，问问自己：有没有一种方法可以让数据库代替为我做这种麻烦事。
3、使用UNION代替UNION ALL
和UNION相比UNION ALL还需要额外的关键字。如果SQL标准已经规定了支持，那么可能会更好点。
UNION（允许重复）UNION DISTINCT （去除了重复）
移除重复行不仅很少需要（有时甚至是错的），而且对于带很多行的大数据集合会相当慢，因为两个子select需要排序，而且每个元组也需要和它的子序列元组比较。
注意即使SQL标准规定了INTERSECT ALL和EXCEPT ALL，很少数据库会实现这些没用的集合操作符。
解决方法：
每次写UNION语句时，考虑实际上是否需要UNION ALL语句。
4、通过JDBC分页技术给大量的结果进行分页操作
大部分的数据库都会支持一些分页命令实现分页效果，譬如LIMIT..OFFSET,TOP..START AT,OFFSET..FETCH语句等。即使没有支持这些语句的数据库，仍有可能对ROWNUM（Oracle）或者是ROW NUMBER()、OVER()过滤（DB2、SQL Server2008等），这些比在内存中实现分页更快速。在处理大量数据中，效果尤其明显。
解决方法：
仅仅使用这些语句，那么一个工具（例如JOOQ）就可以模拟这些语句的操作。
5、在Java内存中加入数据
从SQL的初期开始，当在SQL中使用JOIN语句时，一些开发者仍旧有不安的感觉。这是源自对加入JOIN后会变慢的固有恐惧。假如基于成本的 优化选择去实现嵌套循环，在创建一张连接表源前，可能加载所有的表在数据库内存中，这可能是真的。但是这事发生的概率太低了。通过合适的预测，约束和索 引，合并连接和哈希连接的操作都是相当的快。这完全是是关于正确元数据（在这里我不能够引用Tom Kyte的太多）。而且，可能仍然有不少的Java开发人员加载两张表通过分开查询到一个映射中，并且在某种程度上把他们加到了内存当中。
解决方法：
假如你在各个步骤中有从各种表的查询操作，好好想想是否可以表达你的查询操作在单条语句中。
6、在一个临时的笛卡尔积集合中使用 DISTINCT 或 UNION 消除重复项
通过复杂的连接，人们可能会对SQL语句中扮演关键角色的所有关系失去概念。特别的，如果这涉及到多列外键关系的话，很有可能会忘记在JOIN .. ON子句中增加相关的判断。这会导致重复的记录，但或许只是在特殊的情况下。有些开发者因此可能选择DISTINCT来消除这些重复记录。从三个方面来说 这是错误的：
它（也许）解决了表面症状但并没有解决问题。它也有可能无法解决极端情况下的症状。对具有很多列的庞大的结果集合来说它很慢。DISTINCT要执行ORDER BY操作来消除重复。对庞大的笛卡尔积集合来说它很慢，还是需要加载很多的数据到内存中。
解决方法：
根据经验，如果你获得了不需要的重复记录，还是检查你的JOIN判断吧。可能在某个地方有一个很难觉察的笛卡尔积集合。
7、不使用MERGE语句
这并不是一个过失，但是可能是缺少知识或者对于强悍的MERGE语句信心不足。一些数据库理解其它形式的更新插入（UPSERT）语句， 如 MYSQL的重复主键更新语句，但是MERGE在数据库中确是很强大，很重要，以至于大肆扩展SQL标准，例如SQL SERVER。
解决方法：
如果你使用像联合INSERT和UPDATE或者联合SELECT .. FOR UPDATE然后在INSERT或UPDATE等更新插入时，请三思。你完全可以使用一个更简单的MERGE语句来远离冒险竞争条件。
8、使用聚合函数代替窗口函数（window functions）
在介绍窗口函数之前，在SQL中聚合数据意味着使用GROUP BY语句与聚合函数相映射。在很多情形下都工作得很好，如聚合数据需要浓缩常规数据，那么就在join子查询中使用group查询。
但是在SQL2003中定义了窗口函数，这个在很多主流数据库都实现了它。窗口函数能够在结果集上聚合数据，但是却没有分组。事实上，每个窗口函数都有自己的、独立的PARTITION BY语句，这个工具对于显示报告太好了。
使用窗口函数：
使SQL更易读（但在子查询中没有GROUP BY语句专业）提升性能，像关系数据库管理系统能够更容易优化窗口函数
解决方法：
当你在子查询中使用GROUP BY语句时，请再三考虑是否可以使用窗口函数完成。
9、使用内存间接排序
SQL的ORDER BY语句支持很多类型的表达式，包括CASE语句，对于间接排序十分有用。你可能重来不会在Java内存中排序数据，因为你会想：
SQL排序很慢SQL排序办不到
解决方法：
如果你在内存中排序任何SQL数据，请再三考虑，是否不能在数据库中排序。这对于数据库分页数据十分有用。
10、一条一条地插入大量记录
JDBC“懂”批处理（batch），你应该不会忘了它。不要使用INSERT语句来一条一条的出入成千上万的记录，（因为）每次都会创建一个新 的PreparedStatement对象。如果你的所有记录都插入到同一个表时，那么就创建一个带有一条SQL语句以及附带很多值集合的插入批处理语 句。你可能需要在达到一定量的插入记录后才提交来保证UNDO日志瘦小，这依赖于你的数据库和数据库设置。
解决方法：
总是使用批处理插入大量数据。
来自：OSChina
译者：oschina.net/translate/10-common-mistakes-java-developers-make-when-writing-sql