Home/ Questions/Q 8451873
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-10T11:21:28+00:00

I’m trying to make it quick and easy to perform a keyword search on

  • 0

I’m trying to make it quick and easy to perform a keyword search on a set of MySQL tables which are linked to each other.

There’s a table of items with a unique “itemID” and associated data is spread out amongst other tables, all linked to via the itemID.

I’ve created a view which concatenates much of this information into one usable form. This makes searching really easy, but hasn’t helped with performance. It’s my first use of a view, and perhaps wasn’t the right use. If anyone could give me some pointers I’d be very grateful.

A simplified example is:

ITEMS TABLE:

itemID |  name 
------   -------
   1      "James"
   2      "Bob"
   3      "Mary"

KEYWORDS TABLE:

keywordID |  itemID |  keyword
------      -------   -------
   1           2        "rabbit"
   2           2        "dog"
   3           3        "chicken"

plus many more relations…

MY VIEW: (created using CONCAT_WS, GROUP_CONCAT and a fair few JOINs)

itemID |  important_search_terms 
------   -------
   1      "James ..."
   2      "Bob, rabbit, dog ..."
   3      "Mary, chicken ..."

I can then search the view for “mary” and “chicken” and easily find that itemID=3 matches. Brilliant!

The problem is, it seems to be doing all the work of the CONCATs and JOINs for each and every search which is not efficient. With my current test data searches are taking approx 2 seconds, which is not practical.

I was hoping that the view would be cached in some way, but perhaps I’m not using it in the right way.

I could have an actual table with this search info which I update periodically, but it doesn’t seem as neat as I had hoped.

If anyone has any suggestions I’d be very grateful. Many Thanks

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    Well, a view is nothing more than making it easier to read what you query for but underneath perform the SQL-Statement lying underneath everytime.

    So no wonder it is as slow (even slower…) as when you run that statement itself.

    Usually this is done by indexing jobs (running at nighttime, not annoying anyone), or indexed inserts (when new data is inserted, checks run if it is a good idea to insert them into the indexed interesting words).

    Having that at runtime is really hard and require well designed database structures and most of the time potent hardware for the sql server (depending of data amount).

    • 0