We are having problems with a couchbase N1QL Query.
We have an index defined as follows:
CREATE INDEX `AppUser_SubjectId3` ON `Portal`(`SubjectId`) WHERE ((meta(self).`id`) like `AppUser%`)
We are then trying to run the following query:
SELECT RAW `Extent1`
FROM `Portal` as `Extent1`
USE INDEX (`AppUser_SubjectId3` USING GSI)
WHERE (`Extent1`.`SubjectId` = 'c8ea08231c3a985a06342355b87d6e2d6290a985d5c3592e5b8e5e5f14608a08')
And get the following error:
No index available on keyspace Portal that matches your query.
Use CREATE INDEX or CREATE PRIMARY INDEX to create an index,
or check that your expected index is online.
We have confirmed the obvious that the index is online. The only item worth noting is that the Bucket does not actually contain any documents at the moment, but we would not expect this error in this instance, simply nothing to be returned.
Any ideas?
EDIT:
I have created another index without the WHERE clause and it does not return the error any longer.
CREATE INDEX `AppUser_SubjectId4` ON `Portal`(`SubjectId`)
The only problem is that the WHERE clause is required!
The Index You created is partial index (i.e Index has WHERE clause, only has entries that satisfies where condition). For query to use that index it must qualify (i.e query where clause must be subset of index where clause + query predicate must have leading index key) other wise by choosing that index it can result in wrong results and query optimizer will not choose that index.
Also like AppUser% is incorrect it must be single or double quotes not back-ticks.
CREATE INDEX `AppUser_SubjectId3` ON `test`(`SubjectId`)
WHERE meta().`id` like "AppUser%";
SELECT RAW e
FROM `Portal` AS e
USE INDEX (`AppUser_SubjectId3` USING GSI)
WHERE e.`SubjectId` = 'c8ea08231c3a985a06342355b87d6e2d6290a985d5c3592e5b8e5e5f14608a08'
AND META(e).id LIKE "AppUser%";
Designing Index For Query In Couchbase N1QL https://blog.couchbase.com/wp-content/uploads/2017/10/N1QL-A-Practical-Guide-2nd-Edition.pdf
I tried reproducing your problem successfully, with an empty bucket named test.
I created the same index with the following query :
CREATE INDEX `AppUser_SubjectId3` ON `test`(`SubjectId`) WHERE ((meta(self).`id`) like `AppUser%`)
And checked that the index was online. I then tried your query, which resulted with the exact same error.
[
{
"code": 4000,
"msg": "No index available on keyspace test that matches your query. Use CREATE INDEX or CREATE PRIMARY INDEX to create an index, or check that your expected index is online.",
"query_from_user": "SELECT RAW `Extent1` FROM `test` as `Extent1` USE INDEX (`AppUser_SubjectId3` USING GSI) WHERE (`Extent1`.`SubjectId` = 'c8ea08231c3a985a06342355b87d6e2d6290a985d5c3592e5b8e5e5f14608a08')"
}
]
So I checked the bucket's schema with :
INFER `test`
This returned the following error :
[
{
"code": 0,
"msg": "Keyspace test has no documents, schema inference not possible"
}
]
However I also created a primary index, and querying it would just return an empty results array.
Now I don't really know where to go from this, but it does seem like querying an empty bucket using anything else than a primary index would return this error.
This issue is resolved for me just creating an index over bucket without using any where clause.
Related
I have a table that serves as a foreign key lookup from another table. The table is very simple, containing a ID column with is the primary key and a JSON column. I wish to remove abandoned entries from this table.
I tried running this script:
DELETE
FROM `ate`.`test_configuration`
WHERE `ate`.`test_configuration`.`ID` NOT IN (SELECT DISTINCT `ate`.`index`.`TestID` from `ate`.`index`);
But encountered an error stating my I wasn't using a where clause that uses the key column:
Error Code: 1175. You are using safe update mode and you tried to update a table without a WHERE that uses a KEY column To disable safe mode, toggle the option in Preferences -> SQL Editor and reconnect.
This is confusing as my where clause does use the primary key column. I am aware that I can disable safe mode as part of my script as a workaround, but would still like to understand why I'm getting this error. I'd like to avoid unsafe updates if possible.
I believe Optimizer just unable to use index effectively for such query - so it does full table scan.
How many rows are in the test_configuration and how many of them will be deleted?
(You might try to use index hints to force optimizer to use index for the query, just not sure if they are supported in your version of mysql).
Hopefully a very quick question: I'm having some trouble getting the following
index creation statement to work. I'm using MySQL Workbench.
CREATE INDEX HIRE_DATE_INDEX
ON Employee (hiredate)
WHERE hiredate > '2001-01-01';
I'm trying to get the following index creation to work, however regardless of what I look up online the following is listed as the proper syntax but for some reason that is unfathomable at this point, the index is specifically saying that the where clause is in the incorrect place.
I'm clearly missing something in the examples.
(Context, just trying to create a filtered index only interested in dates greater then).
It looks like this should be easy as hell, what am I missing here?
You don't need the WHERE clause. But MySQL doesn't support filtered index. (Reference here)
CREATE INDEX HIRE_DATE_INDEX
ON Employee (hiredate);
Also that command doesn't work if you try to create a primary key. If that's the case, you need to use ALTER TABLE command.
I want to make a query that select fields using 'like' but I am not satisfied with the result, for example my register says, "wood table work 45" but if my query is SELECT * FROM schema1.table1 WHERE description LIKE "%table for work%"; returns nothing, I don't want the user need write exactly "table work" or "wood table" to have a result.
Create first a FULL TEXT Index on the column you wants to query this way :
ALTER TABLE `table1`
ADD FULLTEXT INDEX `IndxDescription` (`description`);
You don't need to run an indexer daemon, MySQL does the index / reindex automatically.
FYI: Full-text is supported in InnoDB / MyISAM only in MySQL
reference : http://dev.mysql.com/doc/refman/5.7/en/fulltext-restrictions.html
If you are looking for a more robust solution, consider taking a look on ElasticSearch : https://github.com/elastic/elasticsearch
You might want to look at Natural Language Fulltext search
SELECT * FROM orders WITH (INDEX(idx));
When I fired above query I got the error
mysql #1064 - You have an error in your SQL syntax
I have created index as below
create index idx on orders(date,status);
Can anybody tell me the correct syntax?
If the index is appropriate it will be used without explicitly specifying it.
Given you are using SELECT * I would not expect your index to be used (even if the INDEX hint had the correct syntax). The choice is down to the query optimiser's heuristics.
The correct syntax is:
SELECT * FROM orders USE INDEX(idx);
Ref: Index Hints
Also, please note: 99 times out of 100, specifying an Index hint should not be done. Let the optimiser do its job.
I have a table with spatial column(data type geometry) and with around 450k rows. When i tried to add a spatial index on this column, it returns an error as "All parts of a SPATIAL index must be NOT NULL".
The query to create index is
create spatial index spatIdx on table_name(ogc_geom)
1. Am I doing something wrong?
2. Where these NULL parts came from?
3. If its in my spat data how can i remove it (i tried with is null).
In the MySQL documentation, it states, "Currently, columns in spatial indexes must be declared NOT NULL". My guess is the column ogc_geom is allowed to have NULL. Try:
ALTER TABLE table_name MODIFY COLUMN ogc_geom .... NOT NULL
Any column you create a spatial index on must be defined with "NOT NULL", or else you will get an error.
how about if you use the "ALTER TABLE" statement instead to update your table structure and add the index into it.
try to check the sysntax from this link: http://dev.mysql.com/doc/refman/5.5/en/alter-table.html