Jump to content

anon_login_001

Members
  • Posts

    60
  • Joined

  • Last visited

    Never

Profile Information

  • Gender
    Not Telling

anon_login_001's Achievements

Newbie

Newbie (1/5)

0

Reputation

  1. Is there any way you can show the actual error, or better - the actual query being sent?
  2. Well, explain tells me it's looking at a lot of records, and I it seems like it's lagging in the sort. My workplace is moving to a Windows Only environment, even on servers, so my dev box is windows right now - know of any good disk I/O tools that run on Windows?
  3. I have a particular query running 80 - 120 seconds, but uses very little CPU (10% or less) the whole time. Is this common, or does anyone have some direction on where to start looking to resolve this? With CPU this low, I get the feeling that it could be made much faster if MySQL would take more processor power. Any ideas?
  4. I have an index on this table that contains the 'deleted' tinyint() column first, followed by the parent_id varchar(36) column. When I run this query: SELECT * FROM registration_task WHERE name like '%address%' and deleted=0 and status!='Completed' and status!='Not Applicable' and parent_id=120142; an EXPLAIN tells me that it uses the correct index, with a key_len of '1', and that it searches 157,000-some-odd records. Obviously, using only the 'deleted' column of the index. When I add quotes in the query around the parent_id, as such: SELECT * FROM registration_task WHERE name like '%address%' and deleted=0 and status!='Completed' and status!='Not Applicable' and parent_id='120142'; an EXPLAIN shows that the key_len used was 39 (deleted and the parent_id) and it only intends to search '1' row. Can someone please enlighten me about this behavior? I haven't really come accross it before, and am just looking for an explanation of why an Index wouldn't get utilized just because of an unquoted parameter. (though, I know that the param should have been quoted in the first place... I stumbled upon this in the slow query log, and was experimenting for optimization. )
  5. To begin: I've been a developer for quite some time, and although I wouldn't consider myself a "MySQL Expert" on a resume, I am *very* confident in my abilities to do decent MySQL performance tuning. In this case, however, either I'm over-stressed and looking over something, or perhaps I'm truly out of my league and just don't realize it. A company I'm working with has an installation of SugarCRM, which in the past has had some "custom" tabs/features/modules" added to it. Those custom additions are the source of queries that tend to run between 8 and 30 seconds a peice. The queries, unfortunately, are built dynamically - so I'm having a hard time tracking down the best way to handle this situation, although they are mostly consistent. If I'm not mistaken, the version of MySQL is a stable 4.1, on SuSE linux. ----- I'll upload the whole my.cnf if needed, but don't have it at the moment. Though I will mention that: The Query Cache is enabled, and running as effectively as possible. Since the slowest queries are dynamic, with changing search terms, the Query Cache doesn't keep them around anyway, since they're mostly One-offs. The key-buffers are being used consistently, especially during these SELECT queries. The query times are not being inflated by LOCKs... these are all SELECT Queries, and I've watched their status live several times, and there have been no LOCKs. Also: YES, I am aware that there are some OBVIOUSLY poor structural issues. These are in place in a system that has been running for a very long time, and the point of my question is to see if there is anyone with a knowledge beyond my own that can help me make this work better *within my current contraints*. Knowledgeable answers that say "It cannot be done" are perfectly acceptable! I'll be glad to supply any other information. Aside from that, here's one particular problem query example: SELECT users.user_name assigned_user_name, registration.FIELD001 parent_name, registration_task.status status, registration_task.date_modified date_modified, registration_task.date_due date_due, registration.FIELD240 assigned_wf, if(LENGTH(registration_task.description)>0,1,0) has_description, registration_task.* FROM registration_task LEFT JOIN users ON registration_task.assigned_user_id=users.id LEFT JOIN registration ON registration_task.parent_id=registration.id where (registration.FIELD001 LIKE 'schreckengost%') AND registration_task.deleted=0 ORDER BY date_due asc LIMIT 0,20; It's corresponding info from the Slow Query Log: # Query_time: 31 Lock_time: 0 Rows_sent: 20 Rows_examined: 1904929 an EXPLAIN Reveals: id select_type table type possible_keys key key_len ref rows Extra 1 SIMPLE registration_task ref idx_reg_task_p idx_reg_task_p 1 const 464926 Using where; Using filesort 1 SIMPLE users eq_ref PRIMARY PRIMARY 36 sugarcrm401.registration_task.assigned_user_id 1 1 SIMPLE registration eq_ref PRIMARY PRIMARY 8 sugarcrm401.registration_task.parent_id 1 Using where The table structures/create tables statements caused this post to be longer than allowable. They are available at pastebin: http://pastebin.com/m284e3e79 If not obvious, I should add that what I'd like to see are Faster Query Times. The machine is a Quadcore server with 6 Gigs of RAM. I don't have exact specs, but that should say something, at the least.
  6. Frames and New Windows cannot be controlled via Headers/header()
  7. Sorry, my post came after your epiphany. Ignore me. = )
  8. Rather or not it's Normalized, you are showing the potential to run into serious problems in the future. If there is a single login point that checks a username and password against ALL states ... is there ever going to be the possibility that a person in Tennessee will have the same login name as a person in Florida? If so, how do you know which person is trying to login? And if there password is valid?
  9. Because PHP is a Scripting Language. You'll find the definition and execution of Scripted languages -vs- Compiled, etc, is very different. Hit up Google and Wikipedia ... you'll find what you're looking for.
  10. Exactly. It's a simple, hard-coded way to do it... but it gets the job done.
  11. Math is your friend. I suck at math, but this works: You'll have an IF statement in the loop, something like this: if ($picCount % 3 === 0) { // echo '</tr><tr>'; // start a new row! } Assuming $picCount is the number of the current picture, and you'd place that IF statement near the end of the loop. Something like that would check to see if the REMAINDER of the Count, Divided by the Number of Pictures So Far is ZERO. If the number is Zero, obviously you have a number evenly divisible by 3 (in this case)... see how that works?
  12. JD* is correct. The values that get posted are not related to the HTML version rendered, rather the browser sending certain data. Since probably 60+ percent of the world's online forms would be broken if they changed a standard like that, I highly doubt that simply checking for available checkboxen is at all something to concern yourself with. And in another case, when a checkbox is sent, it's name and it's value are sent... no such 'on' state... therefore if they are all named the name and, as deezy says, if all of their values are different, you would still simply check for existing values, since there is no such "On" or "Off" state of a checkbox.
  13. Since I think IFrames are yucky, and because some browser security settings may prevent you from loading contents in your page from an off-site host, you could also have PHP remotely access the Windows server, get the result, and use that in the generated page ... rather than having the generated page access the remote server.
  14. http://www.google.com/search?q=php+scripts http://www.google.com/search?q=php+whois+script I used to use planetsourcecode.com, but I can't remember if they have PHP there or not. Searching this forum ["script sites"?] might also provide better links, as I honestly haven't used a script hosting site in quite some time, and there might be much better suggestions than I have to offer here.
×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.