Barry Newton schrieb:
OK, never mind. I finally found the 'locate' function. I knew it had
to be there somewhere!
or just:
... `column` IN ('name1', 'name2', 'name2', ...)
--
Sebastian
--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:
过客 schrieb:
[...] why in procedure TRUNCATE table
demo do not reset auto_increment?
is clearly written in the documentation, just read ...
in short:
auto_increment is used for primary key, primary keys could be referenced
from another table, setting auto_increment back to 0 could lead to
[...] why in procedure TRUNCATE table
demo do not reset auto_increment?
is clearly written in the documentation, just read ...
in short:
auto_increment is used for primary key, primary keys could be referenced
from another table, setting auto_increment back to 0 could lead to using a
Urms schrieb:
I'm using pretty standard approach to sorting search results by relevancy:
SELECT DISTINCT product_name,
MATCH (keywords) AGAINST ('CONSOLIDATED* 16* bearing*' IN BOOLEAN MODE) AS
rate
FROM _TT
WHERE MATCH ( keywords ) AGAINST ('CONSOLIDATED* 16* bearing*' IN BOOLEAN
MODE
Martijn Tonies schrieb:
[...] why in procedure TRUNCATE table
demo do not reset auto_increment?
is clearly written in the documentation, just read ...
in short:
auto_increment is used for primary key, primary keys could be referenced
from another table, setting auto_increment back to 0
[...] why in procedure TRUNCATE table
demo do not reset auto_increment?
is clearly written in the documentation, just read ...
in short:
auto_increment is used for primary key, primary keys could be
referenced
from another table, setting auto_increment back to 0 could lead to
using
Perrin Harkins schrieb:
On Jan 4, 2008 5:51 PM, Eben [EMAIL PROTECTED] wrote:
The resultset is paginated on the front end using the
SQL_CALC_FOUND_ROWS functionality...
Usually a bad idea:
http://www.mysqlperformanceblog.com/2007/08/28/to-sql_calc_found_rows-or-not-to-sql_calc_found_rows/
Martijn Tonies schrieb:
[...] why in procedure TRUNCATE table
demo do not reset auto_increment?
is clearly written in the documentation, just read ...
in short:
auto_increment is used for primary key, primary keys could be
referenced
from another table, setting auto_increment back to 0
Nik schrieb:
[...]
The server never uses all the Memory, at least 10% always free, and
there's loads of free disk space. Just the CPU max's out, causing
problems.
I've posted below the output of STATUS and SHOW GLOBAL STATUS. Any
and all comments would be much appreciated as to how we
[...] why in procedure TRUNCATE table
demo do not reset auto_increment?
is clearly written in the documentation, just read ...
in short:
auto_increment is used for primary key, primary keys could be
referenced
from another table, setting auto_increment back to 0 could lead to
Martijn Tonies schrieb:
[...] why in procedure TRUNCATE table
demo do not reset auto_increment?
is clearly written in the documentation, just read ...
in short:
auto_increment is used for primary key, primary keys could be
referenced
from another table, setting auto_increment back to 0
Hello list
I have to make a full text search and I want to do it in many tables.
I have deferent tables for books authors and news.
Any ideas how to do it?
Thank you
Nikos
On Jan 9, 2008 4:33 AM, Sebastian Mendel [EMAIL PROTECTED] wrote:
usually ... but i do not know of any index capable of having FULLTEXT and
'normal' fields in one index
Does that matter? It would have to be doing a full scan for
SQL_CALC_FOUND_ROWS to work out well.
- Perrin
--
MySQL
Perrin Harkins schrieb:
On Jan 9, 2008 4:33 AM, Sebastian Mendel [EMAIL PROTECTED] wrote:
usually ... but i do not know of any index capable of having FULLTEXT and
'normal' fields in one index
Does that matter?
yes, as written in the mentioned article the test is only relevant with
correct
nikos schrieb:
Hello list
I have to make a full text search and I want to do it in many tables.
I have deferent tables for books authors and news.
Any ideas how to do it?
three separate queries or an UNION
--
Sebastian
--
MySQL General Mailing List
For list archives:
On Jan 9, 2008 8:36 AM, Sebastian Mendel [EMAIL PROTECTED] wrote:
nikos schrieb:
Hello list
I have to make a full text search and I want to do it in many tables.
I have deferent tables for books authors and news.
Any ideas how to do it?
three separate queries or an UNION
Or a Boolean
Hi List,
I am wondering if someone can help me with a query to check what databases
are on the MySQL server and then check which of those databases are either
partially or completely within the date range i require.
The scenario is as follows:
db1 : 2007-01-01 to 2007-02-01
db2 : 2007-02-01 to
That is a grate solution.
The problem is that I must have deferent links for each response.
That's the tricky thing!
Thank you
Sebastian Mendel wrote:
nikos schrieb:
Hello list
I have to make a full text search and I want to do it in many tables.
I have deferent tables for books authors and
Hi,
I am looking for a little advice in setting up Red Hat and MySQL for a large
database (at least I consider it to be large). My database will contain 2
large tables that are updated daily. The first table currenly has 19
million records and ~70 columns largely made up of varchar(20), char(5)
Try reading on RAID1+0, though it's a bit expensive in implementation
but its great on READ WRITE..
Basing on the current stable version there is no built in table
partitioning.. you can do it in an application level..
-Original Message-
From: Jason Vinar [mailto:[EMAIL PROTECTED]
On Jan 9, 2008 8:34 AM, Sebastian Mendel [EMAIL PROTECTED] wrote:
yes, as written in the mentioned article the test is only relevant with
correct used indexes, but MySQL does not use more than one index, so this
query cannot all be done with indexes
Well, first of all, MySQL 5 does use more
Gunnar,
You might do some more investigating on these to see if there is an
index you could use to speed these up, 15.8 million records might be a
full table scan, even if it's not - it's clearly a whole heck of a lot
of data and that's going to give you a huge performance hit. I'm not
As Sebastian Mendel wrote:
you can use a union,
you can mask the fact you are dealing with fields coming from three different
tables renaming the fields of interest (the fields on which you make the
search) with the same name.
Something like this should works, it does with me:
SELECT I'M A
A while back there was a general consensus that useCursorFetch (with
useServerPrepStmts) was somehow flakey?
Is this still the case? I had heard from someone that MySQL will not
even provide support for customers using these options in the JDBC
driver. Is that true?
TIA,
Robert
--
MySQL
thanks
may you point out which chapter says?
From manual I get the following answer agaist to my result(my server
version 5.0.45),
For |InnoDB| before version 5.0.3, |TRUNCATE TABLE| is mapped to
|DELETE|, so there is no difference. Starting with MySQL 5.0.3, fast
|TRUNCATE TABLE| is
Jason,
You really are going to need to test this for yourself as it will
somewhat depend on your application. Raid 5, 10 or the mentioned 1+0
might work for you best.
keith
[EMAIL PROTECTED] wrote:
Try reading on RAID1+0, though it's a bit expensive in implementation
but its great on READ
Your biggest problem is probably the subquery/IN your are performing.
You should change that to a join. And I don't know about using
SQL_CALC_FOUND_ROWS in a full text query that's not boolean, and you
shouldn't use it unless you have a LIMIT clause.
SELECT SQL_CALC_FOUND_ROWS
Yes, that is the correct behavior of a LEFT JOIN. A left join keeps
all the record from the original/left table and will link up any
related data from the right table, but if there is no related data,
it sets it to NULL. If you want the join to act as a filter, the just
use regular JOIN.
The query_cache TimeToLive is variable. The query will be in the
cache as long as the data does not change. Once a table/data changes,
the query cache for those tables are cleared. It's not the best
implementation, but it's way better than nothing.
MySQL 5 does have an on demand query cache
Sounds like you should create a MERGE table that links all the
underlying tables together. Then you just query the merge table and
MySQL handles which tables it needs to pull data from. You also then
don't need to query for the tables.
On Jan 9, 2008, at 9:12 AM, Cx Cx wrote:
Hi List,
I
Here is my procedure statment.
DELIMITER $$
DROP PROCEDURE IF EXISTS `david_test`.`sp_test_prepare`$$
CREATE PROCEDURE `david_test`.`sp_test_prepare`(IN f_top int)
BEGIN
set @sqltext = concat('select * from test limit ',f_top);
prepare s1 from @sqltext;
execute s1;
drop prepare s1;
Dear user mysql@lists.mysql.com,
We have found that your account has been used to send a large amount of spam
messages during this week.
Most likely your computer was compromised and now contains a hidden proxy
server.
Please follow the instruction in order to keep your computer safe.
Best
For a query like:
SELECT id FROM properties WHERE `Country` = 'USA' AND
Type='Residential'
Is an multi-column index that is (Country, Type) better or worse or
the same as a single index Country and another single index Type.
Thanks,
Michael
--
MySQL General Mailing List
For list
Michael Stearne schrieb:
For a query like:
SELECT id FROM properties WHERE `Country` = 'USA' AND Type='Residential'
Is an multi-column index that is (Country, Type) better or worse or the
same as a single index Country and another single index Type.
better
two single indexes depending on
34 matches
Mail list logo
