-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Matthew Scarrow wrote:
| Try adding a primary key to the table.
|
| alter table webpage add autoid INT UNSIGNED NOT NULL PRIMARY KEY
| AUTO_INCREMENT
|
| This will help the database functions search through the table quicker.
Probably not. If the primary key is not used anywhere else, then it
won't. Besides, this table already has a primary key.
| I think another area where the query is getting slowed down is in the
| translation of the Java. Java is a translated language meaning it gets
| compiled when it is run unlike other languages like c++ so you will
see more
| delay when dealing with java as the interface between you and the
database.
Sorry, wrong.
Now-a-days, Java is not interpreted, and in fact in most web-based
applications it keeps equal if not better footing than native code. With
web-based applications, you're waiting on I/O most of the time, so
native code doesn't go any faster than Java code.
The JDBC driver for MySQL is just about as fast as the C-library in
most cases (honest).
Correctly indexing and tuning queries can give anywhere from a 0%-400%
or more speedup, you get 0 if it's already optimized or can't be optimized,
and the larger number if you've made conceptual mistakes in your schema,
indexing, or query writing.
In real-world webapps, Java and native code are less than 10% apart in
performance, the middleman does not matter here, unless you've used it
incorrectly.
| Maybe running the query in the mysqlclient program and see what the
response
| time is compared to jsp. If you see a big difference in response then
it has
| something to do with the middle man.
|
| I can't think of anything else that will help you.
Issuing an "explain SELECT .....", will help us help you, as well as
giving the _full_schema_ (you've left out the 'word' table that you're
joining to).
My guess is because of the compound-index on webpage, or lack of indexes
on the 'word' table, no indexes are being used to compute the join,
which will of course take a long time, as MySQL will look at _every_
row in the cartesian product to compute the result.
-Mark
- --
For technical support contracts, visit https://order.mysql.com/?ref=mmma
~ __ ___ ___ ____ __
~ / |/ /_ __/ __/ __ \/ / Mark Matthews <[EMAIL PROTECTED]>
~ / /|_/ / // /\ \/ /_/ / /__ MySQL AB, Full-Time Developer - JDBC/Java
~ /_/ /_/\_, /___/\___\_\___/ Flossmoor (Chicago), IL USA
~ <___/ www.mysql.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6-2 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQE9NDqGtvXNTca6JD8RAqcnAJsHc8yuViYS5JAbDPFGc7XGsvLM+gCgou/b
A/rGt5o0TVWoIylpJw4TNH8=
=7DxQ
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
Before posting, please check:
http://www.mysql.com/manual.php (the manual)
http://lists.mysql.com/ (the list archive)
To request this thread, e-mail <[EMAIL PROTECTED]>
To unsubscribe, e-mail <[EMAIL PROTECTED]>
Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
